ColdFusion执行时间准确度

J.T*_*.T. 7 coldfusion

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

以下是问题:

  1. 从底部开始,当ColdFusion报告0ms或16ms时,这是否总是意味着在0到16之间,但不超过16ms?

  2. 当coldfusion报告32毫秒时,这是否意味着介于17和32之间?

  3. ColdFusion默认情况下单独列出所有内容,而不是作为执行树,其中调用者包含许多函数.当确定树上的执行成本更高时,它是否将子项的"不准确"时间相加,或者这是所有子进程执行的实际时间的实际成本?

  4. 我们可以使用cftimers或getTickCount()来实际获得准确的时间,还是这些也是估计?

  5. 有时,你会看到3个函数每个花费4毫秒,总共12毫秒,甚至一个呼叫花费7毫秒.为什么它有时看起来"准确?"

我现在将提供一些猜测,但我想得到一些社区支持!

  1. ColdFusion将跟踪报告准确到16ms的过程总时间,而不是总结子进程.

  2. cftimers和getTickCount()更准确.

  3. 我不知道?

J.T*_*.T. 3

在 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() 有所改进。