System.currentTimeMillis (vs) new Date() vs. Calendar.getInstance(). GetTime()

Question

En Java, ¿cuáles son las implicaciones de rendimiento y recursos de la utilización de

System.currentTimeMillis() 

vs

new Date() 

vs

Calendar.getInstance().getTime() 

Como yo lo entiendo, System.currentTimeMillis() es el más eficiente. Sin embargo, en la mayoría de las aplicaciones, ese valor largo tendría que convertirse en una Fecha u otro objeto similar para hacer algo significativo para los humanos.

Answer 1

System.currentTimeMillis() es obviamente la más eficiente ya que ni siquiera crear un objeto, pero new Date() es realmente sólo un envoltorio delgada sobre una larga, por lo que no se queda atrás. Calendar, por otro lado, es relativamente lento y muy complejo, ya que tiene que lidiar con la considerable complejidad y todas las rarezas que son inherentes a las fechas y horas (años bisiestos, horario de verano, zonas horarias, etc.).

Es generalmente una buena idea para tratar sólo con marcas de tiempo largos o Date objetos dentro de su aplicación, y sólo usar Calendar cuando realmente se necesita realizar cálculos de fecha/hora, o para formatear fechas para mostrarlos al usuario. Si tiene que hacer mucho de esto, usar Joda Time es probablemente una buena idea, para una interfaz más limpia y un mejor rendimiento.

Answer 2

Yo prefiero usar el valor devuelto por System.currentTimeMillis() para todo tipo de cálculos y sólo utilizar CalendarDate o si necesito mostrar realmente un valor que es leído por los seres humanos. Esto también evitará el 99% de sus errores de horario de verano. :)

Answer 3

Si está usando una fecha, le recomiendo encarecidamente que utilice jodatime, http://joda-time.sourceforge.net/. El uso de System.currentTimeMillis() para los campos que son parece una muy mala idea porque terminará con un montón de código inútil.

Tanto la fecha como el calendario están muy trabajados, y Calendar definitivamente es el que tiene el peor rendimiento.

os aconsejo utilizar System.currentTimeMillis() cuando en realidad se está operando con milisegundos, por ejemplo a esto

long start = System.currentTimeMillis(); 
    .... do something ... 
long elapsed = System.currentTimeMillis() -start; 

Answer 4

Mirando el JDK, el constructor más interna de Calendar.getInstance() tiene esto:

public GregorianCalendar(TimeZone zone, Locale aLocale) { 
    super(zone, aLocale); 
    gdate = (BaseCalendar.Date) gcal.newCalendarDate(zone); 
    setTimeInMillis(System.currentTimeMillis()); 
} 

entonces ya hace automáticamente lo que sugieres. por defecto el constructor de la fecha ejerce en este:

public Date() { 
    this(System.currentTimeMillis()); 
} 

Así que en realidad no se necesita para obtener la hora del sistema en concreto a menos que desee hacer algunos cálculos con él antes de la creación de su Calendario/objeto con él. También tengo que recomendar joda-time para utilizar como reemplazo de las clases de calendario/fecha de Java si su propósito es trabajar mucho con los cálculos de fecha.

Answer 5

Dependiendo de su aplicación, puede que desee considerar usar System.nanoTime() en su lugar.

Answer 6

En mi máquina intenté comprobarlo. Mi resultado:

 
Calendar.getInstance().getTime() (*1000000 times) = 402ms 
new Date().getTime(); (*1000000 times) = 18ms 
System.currentTimeMillis() (*1000000 times) = 16ms 

No se olvide de GC (si se utiliza o Calendar.getInstance()new Date())

Answer 7

He intentado esto:

 long now = System.currentTimeMillis(); 
     for (int i = 0; i < 10000000; i++) { 
      new Date().getTime(); 
     } 
     long result = System.currentTimeMillis() - now; 

     System.out.println("Date(): " + result); 

     now = System.currentTimeMillis(); 
     for (int i = 0; i < 10000000; i++) { 
      System.currentTimeMillis(); 
     } 
     result = System.currentTimeMillis() - now; 

     System.out.println("currentTimeMillis(): " + result); 

y el resultado fue:

Fecha() : 199

currentTimeMillis(): 3

Answer 8

System.currentTimeMillis() es obviamente el más rápido porque es solo una llamada a un método y no se necesita un recolector de basura.