Prestazioni: Date.now () vs Date.getTime ()

113

var timeInMs = Date.now();

per MDN

vs.

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

per MDN .

C'è qualche differenza tra i due, oltre alla sintassi e alla possibilità di impostare la Data (a non quella corrente) tramite optional nella seconda versione?

Date.now () è più veloce: controlla il jsperf

javascript

54

per chi se ne frega, Date.now () non funziona nelle versioni di Internet Explorer precedenti a IE9. A me stesso non importa

— guido

8

Per quello che vale, puoi aggiungere lo shim di compatibilità menzionato in developer.mozilla.org/en-US/docs/JavaScript/Reference/… per far funzionare Date.now () anche su IE <9.

— jrajav

jsben.ch/#/TOF9y

— EscapeNetscape

105

Queste cose sono le stesse ( modifica semanticamente; le prestazioni sono leggermente migliori con .now()):

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

Tuttavia, il valore temporale di qualsiasi Dateistanza già creata viene congelato al momento della sua costruzione (o in qualsiasi momento / data su cui è stato impostato). Cioè, se fai questo:

var now = new Date();

e poi aspettare un po ', una successiva chiamata a now.getTime()indicherà l'ora nel punto in cui la variabile è stata impostata.

— pointy
fonte

Pensi che sarebbe più performante creare un oggetto data all'inizio del programma e poi aggiornare semplicemente quell'oggetto data ( dateObj.setTime(Date.now())) o creare nuovi oggetti data ogni volta che fai qualcosa di asincrono che deve accedere a Datemetodi (come dateObj.getMinutes())?

— doubleOrt

3

I runtime JavaScript moderni di @Taurus sono estremamente bravi nella creazione di oggetti e nella raccolta dei rifiuti. A meno che tu non stia lavorando su una sorta di kernel di gioco in tempo reale, non c'è motivo di preoccuparsene. Scrivi un codice che abbia un bell'aspetto e non sia fragile.

— Pointy

1

non dovrei dire grazie ma grazie (spero di non averlo fatto più di una volta).

— doubleOrt

57

Sono effettivamente equivalenti, ma dovresti usare Date.now(). È più chiaro e circa due volte più veloce.

Modifica: fonte: http://jsperf.com/date-now-vs-new-date

— jrajav
fonte

1

È perché Date(optional).getTime();deve allocare spazio per ottenere un nuovo oggetto Date prima di ottenere l'ora corrente?

— Charlie G,

Probabilmente sì. Mi aspetto che abbia più a che fare con tutto ciò che il costruttore Date sta facendo piuttosto che con l'effettiva allocazione dell'oggetto, però.

— jrajav

Sì, l'ho aggiunto frettolosamente: intendevo l'allocazione e tutto ciò che riguarda la creazione di un oggetto.

— Charlie G,

4

Quando lo fai, (new Date()).getTime()stai creando un nuovo oggetto Date. Se lo fai ripetutamente, sarà circa 2 volte più lento di Date.now ()

Lo stesso principio dovrebbe valere per Array.prototype.slice.call(arguments, 0)vs[].slice.call(arguments, 0)

— Gregory Magarshak
fonte

3

Si, è corretto; sono effettivamente equivalenti quando si utilizza l'ora corrente.

— Brett Zamir
fonte

2

A volte è preferibile mantenere una certa variabile di tracciamento del tempo in un formato di oggetto Date piuttosto che come un numero di millisecondi, per avere accesso ai metodi di Date senza reistanziare. In tal caso, Date.now () vince ancora su new Date () o simili, anche se solo di circa il 20% sul mio Chrome e di una piccola quantità su IE.

Vedi il mio JSPERF su

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

vs.

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

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

— SashaK
fonte