Question

我设计了一个程序，旨在测量时间消耗，同时避免微小执行的System.currentTimeMillis()阈值（可能需要不到1毫秒）（它将不可避免地产生额外操作的可接受的不准确性），但是count原来是run()方法中的任何语句都是222（仅限于基本算法）。我无法弄清楚任何可能的解释，听起来不可思议但可能是执行的下限？

public static void main(String[] args) throws Exception{
     long result=TinyTimer(new Runnable(){
        @Override
        public void run(){
            double d=190283758/287365628;
        }
     });
     System.out.println(result);
}

public static long TinyTimer(Runnable r){
    long count=0;
    long origin=System.currentTimeMillis();
    while(System.currentTimeMillis()==origin){
        r.run();
        count++;
    }
    return count;
}

Answer 1

你应该注意到

在一些较旧的Windows系统上，System.currentTimeMillis（）的分辨率为16毫秒，而不是1毫秒。
没有预热的代码的性能，作为一种练习很有意思，但很少与生产系统相关。我建议你至少忽略前2秒的热身。
无法执行任何操作的代码。在这种情况下，您应该期望消除代码，并且您在预热后的所有时间是调用System.currentTimeMillis()所需的时间，根据您的CPU，该时间应在25 - 50纳秒之间。

我建议您使用JMH（Java Microbenchamrk Harness），它旨在处理编写微基准测试时的大多数常见错误。

但是计数结果是222（run（）方法中的任何语句都是（仅限于基本算法）

最有可能花时间运行解释器来执行此代码并且开销很高，您选择的操作并没有太大的区别。

是否有Java的执行时间下限？

1 个答案: