Накладные расходы на измерение времени в Java

Ответ, помеченный как правильный на этой странице, на самом деле неверен. Это недопустимый способ написания эталонного теста из-за устранения мертвого кода JVM (DCE), замены в стеке (OSR), развертывания циклов и т. д. Только такая среда, как среда микротестирования Oracle JMH, может правильно измерить что-то подобное. Прочитайте это сообщение, если у вас есть какие-либо сомнения относительно достоверности таких микротестов.

Вот тест JMH для System.currentTimeMillis() против System.nanoTime():

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
public class NanoBench {
   @Benchmark
   public long currentTimeMillis() {
      return System.currentTimeMillis();
   }

   @Benchmark
   public long nanoTime() {
    return System.nanoTime();
   }
}

И вот результаты (на Intel Core i5):

Benchmark                            Mode  Samples      Mean   Mean err    Units
c.z.h.b.NanoBench.currentTimeMillis  avgt       16   122.976      1.748    ns/op
c.z.h.b.NanoBench.nanoTime           avgt       16   117.948      3.075    ns/op

Что показывает, что System.nanoTime() немного быстрее ~ 118 нс на вызов по сравнению с ~ 123 нс. Однако также ясно, что после учета средней ошибки разница между ними очень мала. Результаты также могут различаться в зависимости от операционной системы. Но общий вывод должен заключаться в том, что они по существу эквивалентны с точки зрения накладных расходов.

ОБНОВЛЕНИЕ 2015/08/25: хотя этот ответ ближе к правильному, чем большинство, с использованием JMH для измерения, он все же неверен. Измерение чего-то вроде System.nanoTime() — это особый вид искаженного бенчмаркинга. Ответ и исчерпывающая статья находятся здесь.

Я не думаю, что вам нужно беспокоиться о накладных расходах. Она настолько минимальна, что едва ли может быть измерена сама по себе. Вот быстрый микро-тест обоих:

for (int j = 0; j < 5; j++) {
    long time = System.nanoTime();
    for (int i = 0; i < 1000000; i++) {
        long x = System.currentTimeMillis();
    }
    System.out.println((System.nanoTime() - time) + "ns per million");

    time = System.nanoTime();
    for (int i = 0; i < 1000000; i++) {
        long x = System.nanoTime();
    }
    System.out.println((System.nanoTime() - time) + "ns per million");

    System.out.println();
}

И последний результат:

14297079ns per million
29206842ns per million

Похоже, что System.currentTimeMillis() в два раза быстрее, чем System.nanoTime(). Однако 29 нс будет намного короче, чем все остальное, что вы все равно измеряете. Я бы выбрал System.nanoTime() из-за точности и правильности, так как это не связано с часами.

Вы должны использовать только System.nanoTime() для измерения того, сколько времени требуется для выполнения чего-либо. Дело не только в точности в наносекундах, System.currentTimeMillis() — это «время настенных часов», в то время как System.nanoTime() предназначено для хронометража и не имеет причуд «реального мирового времени», которые есть у других. Из Javadoc System.nanoTime():

Этот метод можно использовать только для измерения прошедшего времени и он не связан ни с каким другим понятием системного или настенного времени.

Если у вас есть время, посмотрите выступление Клиффа Клик., он говорит о цене System.currentTimeMillis, а также о других вещах.

System.currentTimeMillis() обычно очень быстрый (насколько известно, 5-6 циклов процессора, но я не знаю, где я это читал), но его разрешение зависит от разных платформ.

Поэтому, если вам нужна высокая точность, выберите nanoTime(), если вас беспокоят накладные расходы, выберите currentTimeMillis().

Принятый ответ на этот вопрос действительно неверен. Альтернативный ответ, предоставленный @brettw, хорош, но, тем не менее, не содержит деталей.

Для полного рассмотрения этого вопроса и реальной стоимости этих вызовов см. https://shipilev.net/blog/2014/nanotrusting-nanotime/

Чтобы ответить на заданный вопрос:

кто-нибудь знает, есть ли какие-либо существенные накладные расходы, вызывающие тот или иной?

• Накладные расходы на вызов System#nanoTime составляют от 15 до 30 наносекунд на вызов.
• Значение, сообщаемое nanoTime, его разрешение, изменяется только один раз в 30 наносекунд.

Это означает, что в зависимости от того, пытаетесь ли вы выполнять миллион запросов в секунду, вызов nanoTime означает, что вы фактически теряете огромную часть второго вызова nanoTime. В таких случаях рассмотрите возможность измерения запросов со стороны клиента, чтобы не попасть в согласованное упущение, измерение глубины очереди также является хорошим индикатором.

Если вы не пытаетесь втиснуть как можно больше работы в одну секунду, то nanoTime не будет иметь большого значения, но скоординированное упущение все еще имеет значение.

Наконец, для полноты картины currentTimeMillis нельзя использовать независимо от ее стоимости. Это связано с тем, что не гарантируется переход вперед между двумя вызовами. Особенно на сервере с NTP currentTimeMillis постоянно перемещается. Не говоря уже о том, что большинство вещей, измеряемых компьютером, не занимают целую миллисекунду.

На теоретическом уровне для виртуальной машины, использующей собственные потоки и работающей в современной операционной системе с вытеснением, currentTimeMillis можно реализовать так, чтобы она читалась только один раз за квант времени. Предположительно, реализации nanoTime не пожертвуют точностью.

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