Tiempo de medición de gastos generales en Java

Question

Cuando se mide el tiempo transcurrido en un nivel bajo, que tiene la opción de usar cualquiera de estos:

System.currentTimeMillis(); 
System.nanoTime(); 

se implementan Ambos métodos native. Antes de profundizar en cualquier código C, ¿alguien sabe si hay alguna sobrecarga sustancial llamando a uno u otro? Quiero decir, si realmente no me importa la precisión adicional, ¿cuál se esperaría que tomara menos tiempo de CPU?

N.B: Estoy usando el estándar de Java JDK 1.6, pero la pregunta puede ser válido para cualquier JRE ...

Answer 1

no creo que hay que preocuparse por la sobrecarga de cualquiera. Es tan mínimo que apenas se puede medir. Aquí hay una rápida micro de referencia de ambos:

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(); 
} 

Y el último resultado:

14297079ns per million 
29206842ns per million 

sí parece que es System.currentTimeMillis() doble de rápido que System.nanoTime(). Sin embargo, 29ns va a ser mucho más corto que cualquier otra cosa que medirías de todos modos. Me gustaría obtener System.nanoTime() para obtener precisión y precisión ya que no está asociado con relojes.

Answer 2

System.currentTimeMillis() es generalmente muy rápido (afaik 5-6 ciclos de CPU pero no sé dónde lo he leído más), pero su resolución varía en diferentes plataformas.

Así que si necesita alta precisión, vaya a nanoTime(), si le preocupa la sobrecarga, vaya a currentTimeMillis().

Answer 3

Solo debe utilizar System.nanoTime() para medir el tiempo que tarda en ejecutarse. No es solo una cuestión de precisión de nanosegundos, System.currentTimeMillis() es "tiempo de reloj de pared", mientras que System.nanoTime() está diseñado para cronometrar las cosas y no tiene los caprichos del "tiempo del mundo real" que tiene el otro. Desde el Javadoc de System.nanoTime():

Este método sólo se puede utilizar para medir el tiempo transcurrido y no está relacionado con ninguna otra noción de sistema o de pared reloj de tiempo.

Answer 4

A nivel teórico, para una máquina virtual que utiliza hilos nativos, y se sienta en un sistema operativo preventivo moderna, los currentTimeMillis se pueden implementar para ser leído sólo una vez por segmento de tiempo. Presumiblemente, las implementaciones de nanoTime no sacrificarían la precisión.

Answer 5

Si tienes tiempo, mira this talk by Cliff Click, habla del precio de System.currentTimeMillis, entre otras cosas.

Answer 6

La respuesta correcta en esta página no es correcta. Esa no es una forma válida de escribir un punto de referencia debido a la eliminación de código muerto (DCE) de JVM, reemplazo en la pila (OSR), desenrollado de bucles, etc. Solo un marco como el marco de micro-benchmarking JMH de Oracle puede medir algo así. Lea this post si tiene alguna duda sobre la validez de dichos micro benchmarks.

Aquí es un punto de referencia JMH para System.currentTimeMillis() vs 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(); 
    } 
} 

Y aquí están los resultados (en un procesador 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 

lo que demuestra que System.nanoTime() es ligeramente más rápido en ~ 118ns por invocación en comparación con ~ 123ns. Sin embargo, también está claro que una vez que se tiene en cuenta el error medio, hay muy poca diferencia entre los dos. Los resultados también pueden variar según el sistema operativo. Pero la conclusión general debería ser que son esencialmente equivalentes en términos de sobrecarga.

ACTUALIZACIÓN 2015/08/25: Si bien esta respuesta está más cerca de corregir la mayoría, utilizando JMH para medir, todavía no es correcta. Medir algo como System.nanoTime() en sí mismo es un tipo especial de benchmarking retorcido. La respuesta y el artículo definitivo es here.

Answer 7

La respuesta aceptada a esta pregunta es incorrecta. La respuesta alternativa provista por @brettw es buena pero, sin embargo, poco esclarecedora.

Para un tratamiento completo de este tema y el costo real de estas llamadas, por favor ver https://shipilev.net/blog/2014/nanotrusting-nanotime/

Para responder a la pregunta:

¿alguien sabe si hay alguna sobrecarga sustancial llamando a uno o ¿el otro?

• La sobrecarga de llamar System#nanoTime es de entre 15 a 30 nanosegundos por llamada.
• El valor reportado por nanoTime, su resolución, sólo cambia una vez por 30 nanosegundos

Esto significa dependiendo de si usted está tratando de hacer millones de peticiones por segundo, llamando nanoTime significa que está perdiendo una gran eficacia parte de la segunda llamada nanoTime. Para estos casos de uso, considere la posibilidad de medir las solicitudes desde el lado del cliente, asegurándose así de que no caiga en el coordinated omission, la medición de la profundidad de la cola también es un buen indicador.

Si no está tratando de meter todo el trabajo que pueda en un solo segundo, entonces nanoTime en realidad no importará, pero la omisión coordinada sigue siendo un factor.

Finalmente, para completar, currentTimeMillis no se puede utilizar sin importar su costo. Esto se debe a que no se garantiza que avance entre dos llamadas. Especialmente en un servidor con NTP, currentTimeMillis se mueve constantemente. Sin mencionar que la mayoría de las cosas medidas por una computadora no toman un milisegundo completo.