Performances - Date.now () vs Date.getTime ()

113

var timeInMs = Date.now();

par MDN

contre.

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

par MDN .

Y a-t-il une différence entre les deux, en plus de la syntaxe et de la possibilité de définir la date (pas la date actuelle) via facultatif dans la deuxième version?

Date.now () est plus rapide - consultez le jsperf

javascript

55

pour quiconque s'en soucie, Date.now () ne fonctionne pas dans les versions d'Internet Explorer antérieures à IE9. Je m'en fiche

— guido

8

Pour ce que ça vaut, vous pouvez ajouter le shim de compatibilité mentionné dans developer.mozilla.org/en-US/docs/JavaScript/Reference/... pour que Date.now () fonctionne également sur IE <9.

— jrajav

jsben.ch/#/TOF9y

— EscapeNetscape

105

Ces choses sont les mêmes ( modifier sémantiquement; les performances sont un peu meilleures avec .now()):

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

Cependant, la valeur de temps de toute Dateinstance déjà créée est gelée au moment de sa construction (ou à n'importe quelle heure / date à laquelle elle a été définie). Autrement dit, si vous faites ceci:

var now = new Date();

puis attendez un moment, un appel ultérieur à now.getTime()indiquera l'heure au moment où la variable a été définie.

— Pointu
source

Pensez-vous qu'il serait plus performant de créer un objet de date au début du programme, puis de simplement mettre à jour cet objet de date ( dateObj.setTime(Date.now())) ou de créer de nouveaux objets de date à chaque fois que vous faites quelque chose d'asynchrone qui nécessite d'accéder à des Dateméthodes (telles que dateObj.getMinutes())?

— doubleOrt

3

Les runtimes JavaScript modernes de @Taurus sont extrêmement bons pour la création d'objets et le ramasse-miettes. À moins que vous ne travailliez sur une sorte de noyau de jeu en temps réel, il n'y a aucune raison de s'en inquiéter. Écrivez un code qui a l'air bien et qui n'est pas fragile.

— Pointy

1

pas censé dire merci mais merci (j'espère ne pas l'avoir fait plus d'une fois).

— doubleOrt

57

Ils sont effectivement équivalents, mais vous devriez les utiliser Date.now(). C'est plus clair et environ deux fois plus rapide.

Edit: Source: http://jsperf.com/date-now-vs-new-date

— jrajav
source

1

Est-ce parce que Date(optional).getTime();doit allouer de l'espace pour obtenir un nouvel objet Date avant d'obtenir l'heure actuelle?

— Charlie G

Probablement oui. Je m'attendrais à ce que cela ait plus à voir avec tout ce que fait le constructeur Date plutôt qu'avec l'allocation réelle de l'objet, cependant.

— jrajav

Ouais, j'ai ajouté ça hasily - je voulais dire l'allocation et tout ce qui va avec la création d'un objet.

— Charlie G

4

Lorsque vous (new Date()).getTime()créez un nouvel objet Date. Si vous faites cela à plusieurs reprises, ce sera environ 2x plus lent que Date.now ()

Le même principe devrait s'appliquer pour Array.prototype.slice.call(arguments, 0)vs[].slice.call(arguments, 0)

— Grégory Magarshak
source

3

Oui c'est correct; ils sont effectivement équivalents lors de l'utilisation de l'heure actuelle.

— Brett Zamir
source

2

Parfois, il est préférable de conserver une variable de suivi du temps dans un format d'objet Date plutôt que juste un nombre de millisecondes, pour avoir accès aux méthodes de Date sans ré-instancier. Dans ce cas, Date.now () l'emporte toujours sur la nouvelle Date () ou similaire, mais seulement d'environ 20% sur mon Chrome et d'une petite quantité sur IE.

Voir mon JSPERF sur

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

contre.

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

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

— SashaK
source