Rendimiento: Date.now () frente a Date.getTime ()

113

var timeInMs = Date.now();

por MDN

vs.

var timeInMs = new Date(optional).getTime();

por MDN .

¿Hay alguna diferencia entre los dos, además de la sintaxis y la capacidad de establecer la fecha (que no sea la actual) a través de opcional en la segunda versión?

Date.now () es más rápido: echa un vistazo al jsperf

javascript

54

para cualquiera que se preocupe, Date.now () no funciona en versiones de Internet Explorer anteriores a IE9. A mí mismo no me importa

— guido

8

Por lo que vale, puede agregar la corrección de compatibilidad mencionada en developer.mozilla.org/en-US/docs/JavaScript/Reference/… para que Date.now () también funcione en IE <9.

— jrajav

jsben.ch/#/TOF9y

— EscapeNetscape

105

Estas cosas son las mismas ( editar semánticamente; el rendimiento es un poco mejor con .now()):

var t1 = Date.now();
var t2 = new Date().getTime();

Sin embargo, el valor de tiempo de cualquier Dateinstancia ya creada se congela en el momento de su construcción (o en cualquier fecha / hora en la que se haya configurado). Es decir, si haces esto:

var now = new Date();

y luego espere un momento, una llamada posterior a now.getTime()le dirá la hora en el punto en que se estableció la variable.

— Puntiagudo
fuente

¿Crees que sería más eficaz crear un objeto de fecha al principio del programa y luego simplemente actualizar ese objeto de fecha ( dateObj.setTime(Date.now())) o crear nuevos objetos de fecha cada vez que haces algo asincrónico que necesita acceder a Datemétodos (como dateObj.getMinutes())?

— doubleOrt

3

Los tiempos de ejecución de JavaScript modernos de @Taurus son extremadamente buenos para la creación de objetos y la recolección de basura. A menos que esté trabajando en algún tipo de kernel de juego en tiempo real, no hay ninguna razón para preocuparse por eso. Escriba un código que se vea bien y no sea frágil.

— Puntiagudo

1

Se supone que no debo dar las gracias, pero gracias (espero no haberlo hecho más de una vez).

— doubleOrt

57

Son efectivamente equivalentes, pero debes usar Date.now(). Es más claro y aproximadamente el doble de rápido.

Editar: Fuente: http://jsperf.com/date-now-vs-new-date

— jrajav
fuente

1

¿Es esto porque Date(optional).getTime();tiene que asignar espacio para obtener un nuevo objeto Date antes de obtener la hora actual?

— Charlie G

Probablemente si. Sin embargo, esperaría que tenga más que ver con todo lo que está haciendo el constructor Date que con la asignación real del objeto.

— jrajav

Sí, lo agregué rápidamente: me refería a la asignación y todo lo que conlleva la creación de un objeto.

— Charlie G

4

Cuando lo hace (new Date()).getTime(), está creando un nuevo objeto Date. Si hace esto repetidamente, será aproximadamente 2 veces más lento que Date.now ()

El mismo principio debería aplicarse para Array.prototype.slice.call(arguments, 0)vs[].slice.call(arguments, 0)

— Gregory Magarshak
fuente

3

Si, eso es correcto; son efectivamente equivalentes cuando se usa la hora actual.

— Brett Zamir
fuente

2

A veces es preferible mantener alguna variable de seguimiento de tiempo en un formato de objeto Date en lugar de solo una cantidad de milisegundos, para tener acceso a los métodos de Date sin volver a crear instancias. En ese caso, Date.now () todavía gana sobre el nuevo Date () o similar, aunque solo en aproximadamente un 20% en mi Chrome y en una pequeña cantidad en IE.

Ver mi JSPERF en

timeStamp2.setTime(Date.now()); // set to current;

vs.

timeStamp1 = new Date(); // set to current;

http://jsperf.com/new-date-vs-settime

— SashaK
fuente