Question

我从2004年发现very old thread报告了ColdFusion调试输出中列出的执行时间仅精确到16ms的事实。这意味着，当您打开调试输出并查看执行时间时，您会看到最接近的16ms的估计值。今天我可以用ACF10看到这个。刷新页面时，大多数时间在15-16ms的倍数之间反弹。

以下是问题：

从底部开始，当ColdFusion报告0ms或16ms时，确实如此总是指0到16之间，但不超过16ms？
当coldfusion报告32毫秒时，这是否介于两者之间 17和32？
ColdFusion默认情况下单独列出所有内容而不是一个执行树，其中调用者包含许多函数。什么时候确定树上的执行成本更高，是否相加孩子们的“不确定”时代，或者这是一个现实的代价所有子进程执行的实际时间？
我们可以使用cftimers或getTickCount（）来实际获得准确时间，或者这些也是估计？
有时，你会看到3个函数每个花费4毫秒，总共12毫秒，甚至一个呼叫花费7毫秒。为什么它有时看起来“准确？”

我现在会提供一些猜测，但我想得到一些社区支持！

是
是
ColdFusion将跟踪报告的准确时间为16毫秒，而不是总结子流程。
cftimers和getTickCount（）更准确。
我不知道？

Answer 1

在Java中，您可以使用System.currentTimeMillis（）或System.nanoTime（）。

我假设getTickCount（）只返回System.currentTimeMillis（）。 ColdFusion也使用它来报告调试输出执行时间。您可以在众多StackOverflow问题上找到抱怨System.currentTimeMillis（）不准确的问题，因为它是来自操作系统的报告。在Windows上，准确度可能会有很大差异，有人说可达50毫秒。它没有考虑到飞跃的问题或任何事情。但是，它很快。查询似乎报告来自JDBC驱动程序，SQL引擎或其他方法的内容，因为它们通常是准确的。

作为替代方案，如果您真的想要提高准确度，可以使用：

currentTime = CreateObject("java", "java.lang.System").nanoTime()

这比currentTimeMillis（）的性能低，但精确到纳秒级。你可以除以1000来达到微秒。如果您尝试通过除以1000000转换为毫秒，则需要包装precisionEvaluate（）。

请注意，nanoTime（）不准确到纳秒，精确到纳秒。它的准确性只是对currentTimeMillis（）的改进。

Answer 2

这是一个评论然后回答，但我还不能发表评论。

根据我的经验，查询的最短执行时间是0毫秒或16毫秒。它永远不会是8毫秒或9毫秒。为了好玩，你可以试试这个：

<cfset s = gettickcount()>
<cfset sleep(5)>
<cfset e = gettickcount() -s>
<Cfoutput>#e#</cfoutput>

我尝试使用不同的值，看起来预期的输出和实际输出总是在0ms到16ms的范围内，无论使用什么值。似乎coldfusion（java）是准确的，边距约为16毫秒。

ColdFusion执行时间准确度

2 个答案: