我发现2004年的一个非常旧的线程报告了ColdFusion调试输出中列出的执行时间仅精确到16ms的事实.这意味着,当您打开调试输出并查看执行时间时,您会看到最接近的16ms的估计值.今天我可以用ACF10看到这个.刷新页面时,大多数时间在15-16ms的倍数之间反弹.
以下是问题:
从底部开始,当ColdFusion报告0ms或16ms时,这是否总是意味着在0到16之间,但不超过16ms?
当coldfusion报告32毫秒时,这是否意味着介于17和32之间?
ColdFusion默认情况下单独列出所有内容,而不是作为执行树,其中调用者包含许多函数.当确定树上的执行成本更高时,它是否将子项的"不准确"时间相加,或者这是所有子进程执行的实际时间的实际成本?
我们可以使用cftimers或getTickCount()来实际获得准确的时间,还是这些也是估计?
有时,你会看到3个函数每个花费4毫秒,总共12毫秒,甚至一个呼叫花费7毫秒.为什么它有时看起来"准确?"
我现在将提供一些猜测,但我想得到一些社区支持!
是
是
ColdFusion将跟踪报告准确到16ms的过程总时间,而不是总结子进程.
cftimers和getTickCount()更准确.
我不知道?
在 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() 有所改进。
| 归档时间: |
|
| 查看次数: |
1205 次 |
| 最近记录: |