2016-04-06 2 views
2

Я разработал программу, предназначенную для измерения расхода времени, а во избежание порога System.currentTimeMillis() для крошечного выполнения (может занять менее 1 миллиметра) (это неизбежно приведет к допустимой неточности для дополнительных операций), но count окажется 222 любых утверждений внутри Метод run() (ограничен базовыми алгоритмами). Я не могу понять какое-либо возможное объяснение, звучит невероятно, но, возможно, нижний предел для исполнения?Есть ли нижняя граница времени выполнения для Java?

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; 
} 
+0

Я уверен, что вы можете получить меньше 222, если вы поместите много операций в метод (например, Thread.sleep). – Thilo

+1

Вы можете использовать System.nanoTime для более точных измерений. – Thilo

+1

Странно, я несколько раз запускал ваш код и получал счета от 2000 до 700 000. –

ответ

2

Следует отметить, что

  • разрешение System.currentTimeMillis() составляет 16 мс на некоторых старых оконных систем, а не 1 мс.
  • Выполнение кода, который не прогрелся, интересен как упражнение, но редко относится к производственной системе. Я предлагаю вам игнорировать первые 2 секунды разминки по крайней мере.
  • код, который не делает ничего, может быть устранен с помощью устранения Dead Code. В этом случае вы должны ожидать, что код будет устранен, и все ваши настройки времени после прогрева - это время, которое требуется для вызова System.currentTimeMillis(), который должен составлять от 25 до 50 наносекунд в зависимости от вашего процессора.

Я предлагаю вам взглянуть на использование JMH (Java Microbenchamrk сбруи), который предназначен для обработки наиболее распространенных ошибок в написании микро-тестов.

но граф оказывается 222 независимо операторы внутри метода Run() являются (ограничивается основными алгоритмами)

Скорее всего времени проводят работы интерпретатора, чтобы выполнить этот кодекс и накладные расходы настолько высоки, что ваш выбор не имеет большого значения.

+0

Выбор операции не имеет значения, поскольку эти операции оцениваются во время компиляции. И '222', кажется, очень специфичен для окружающей среды OP. В качестве примечания, оптимизатор может даже удалить служебные данные 'currentTimeMillis()', когда он понимает свою семантику. Таким образом, весь метод 'TinyTimer' может быть заменен на« подождите не менее одной миллисекунды и возвращает произвольное значение «long'» ... – Holger

+0

@Holger System.currentTimeMillis() может быть удален только при условии замены другого таймера. Я никогда не видел, чтобы Oracle JDK делал это. У этого есть понимание ограниченного набора методов, и это не один из них. –

+0

Я не говорю, что это происходит сегодня, но все же 'System.currentTimeMillis()' [является встроенной функцией] (http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src /share/vm/classfile/vmSymbols.hpp#l700), поэтому оптимизатор должен это знать, независимо от того, знает ли он, как его преодолеть. – Holger

 Смежные вопросы

  • Нет связанных вопросов^_^