Wydajność - Date.now () vs Date.getTime ()

113

var timeInMs = Date.now();

na MDN

vs.

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

na MDN .

Czy jest jakaś różnica między nimi, poza składnią i możliwością ustawienia daty (nie bieżącej) za pomocą opcji opcjonalnej w drugiej wersji?

Date.now () jest szybsze - sprawdź jsperf

javascript

55

dla każdego, kogo to obchodzi, Date.now () nie działa w wersjach Internet Explorer wcześniejszych niż IE9. Sama mnie to nie obchodzi

— guido

8

Co jest warte, możesz dodać podkładkę zgodności wymienioną w developer.mozilla.org/en-US/docs/JavaScript/Reference/ ..., aby Date.now () działała również w IE <9.

— jrajav,

jsben.ch/#/TOF9y

— EscapeNetscape

105

Te rzeczy są takie same ( edycja semantyczna; wydajność jest trochę lepsza z .now()):

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

Jednak wartość czasu z dowolnej już utworzonej Dateinstancji jest zamrażana w momencie jej tworzenia (lub w jakimkolwiek czasie / dacie, na którą została ustawiona). To znaczy, jeśli to zrobisz:

var now = new Date();

a następnie odczekaj chwilę, kolejne wywołanie now.getTime()wskaże czas w punkcie, w którym zmienna została ustawiona.

— Spiczasty
źródło

Czy uważasz, że wydajniejsze byłoby utworzenie jednego obiektu daty na początku programu, a następnie po prostu zaktualizowanie tego obiektu daty ( dateObj.setTime(Date.now())) lub utworzenie nowych obiektów daty za każdym razem, gdy robisz coś asynchronicznego, co wymaga dostępu do Datemetod (takich jak dateObj.getMinutes())?

— doubleOrt

3

Nowoczesne środowiska wykonawcze JavaScript @Taurus są wyjątkowo dobre w tworzeniu obiektów i usuwaniu elementów bezużytecznych. Jeśli nie pracujesz nad jakimś jądrem gry w czasie rzeczywistym, nie ma powodu, aby się tym martwić. Napisz kod, który wygląda dobrze i nie jest kruchy.

— Pointy

1

nie powinienem podziękować, ale dzięki (mam nadzieję, że nie zrobiłem tego więcej niż raz).

— doubleOrt

57

Są efektywnie równoważne, ale powinieneś użyć Date.now(). Jest wyraźniejszy i około dwa razy szybszy.

Edycja: źródło: http://jsperf.com/date-now-vs-new-date

— jrajav
źródło

1

Czy to dlatego, Date(optional).getTime();że trzeba przydzielić miejsce, aby uzyskać nowy obiekt Date przed uzyskaniem aktualnego czasu?

— Charlie G

Prawdopodobnie tak. Spodziewałbym się jednak, że ma to więcej wspólnego ze wszystkim, co robi konstruktor Date, niż z faktyczną alokacją obiektu.

— jrajav,

Tak, dodałem to pospiesznie - miałem na myśli alokację i wszystko, co wiąże się z tworzeniem obiektu.

— Charlie G,

4

Kiedy to zrobisz (new Date()).getTime(), tworzysz nowy obiekt Date. Jeśli będziesz to powtarzać, będzie to około 2x wolniejsze niż Date.now ()

Ta sama zasada powinna mieć zastosowanie do Array.prototype.slice.call(arguments, 0)vs[].slice.call(arguments, 0)

— Gregory Magarshak
źródło

3

Tak to jest poprawne; są one efektywnie równoważne przy używaniu czasu bieżącego.

— Brett Zamir
źródło

2

Czasami lepiej jest zachować pewną zmienną śledzenia czasu w formacie obiektu Date, a nie tylko liczbę milisekund, aby mieć dostęp do metod Date bez ponownego tworzenia instancji. W takim przypadku Date.now () nadal wygrywa z nową Date () lub podobną, ale tylko o około 20% na moim Chrome i niewielką kwotę w IE.

Zobacz mój JSPERF na

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

vs.

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

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

— SashaK
źródło