Производительность - Date.now () vs Date.getTime ()

113

var timeInMs = Date.now();

за MDN

vs.

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

за MDN .

Есть ли какая-то разница между ними, кроме синтаксиса и возможности установить дату (не текущую) через опцию во второй версии?

Date.now () работает быстрее - проверьте jsperf

javascript

55

для всех, кому не все равно, Date.now () не работает в версиях Internet Explorer до IE9. Мне самому все равно

— гвидо

8

Что бы это ни стоило, вы можете добавить прокладку совместимости, упомянутую в developer.mozilla.org/en-US/docs/JavaScript/Reference/…, чтобы заставить Date.now () работать и в IE <9.

— jrajav

jsben.ch/#/TOF9y

— EscapeNetscape

105

Это то же самое ( редактировать семантически; производительность немного лучше .now()):

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

Однако значение времени из любого уже созданного Dateэкземпляра замораживается во время его создания (или в любое время / дату, на которые оно было установлено). То есть, если вы сделаете это:

var now = new Date();

а затем подождать некоторое время, последующий вызов now.getTime()сообщит время в точке переменная была установлена.

— Заостренный
источник

Как вы думаете, было бы более производительным создать один объект даты в начале программы, а затем просто обновлять этот объект даты ( dateObj.setTime(Date.now())) или создавать новые объекты даты каждый раз, когда вы делаете что-то асинхронное, требующее доступа к Dateметодам (например, dateObj.getMinutes())?

— doubleOrt

3

Современные среды выполнения JavaScript @Taurus чрезвычайно хороши в создании объектов и сборке мусора. Если вы не работаете над каким-то ядром для игры в реальном времени, нет никаких причин для беспокойства по этому поводу. Пишите код, который хорошо выглядит и не является хрупким.

— Pointy

1

не должен говорить спасибо, но спасибо (надеюсь, я не делал этого больше одного раза).

— doubleOrt

57

Они фактически эквивалентны, но вы должны использовать Date.now(). Это четче и примерно в два раза быстрее.

Изменить: Источник: http://jsperf.com/date-now-vs-new-date

— Джраджав
источник

1

Это потому, Date(optional).getTime();что нужно выделить место для получения нового объекта Date до получения текущего времени?

— Charlie G

Возможно - да. Я ожидал, что это больше связано со всем, что делает конструктор Date, а не с фактическим распределением объекта.

— jrajav

Да, я добавил это поспешно - я имел в виду распределение и все, что связано с созданием объекта.

— Charlie G

4

Когда вы это делаете, (new Date()).getTime()вы создаете новый объект Date. Если вы сделаете это несколько раз, это будет примерно в 2 раза медленнее, чем Date.now ().

Тот же принцип должен применяться к Array.prototype.slice.call(arguments, 0)vs[].slice.call(arguments, 0)

— Григорий Магаршак
источник

3

Да, это правильно; они фактически эквивалентны при использовании текущего времени.

— Бретт Замир
источник

2

Иногда предпочтительнее сохранить некоторую переменную отслеживания времени в формате объекта Date, а не в виде количества миллисекунд, чтобы иметь доступ к методам Date без повторного создания экземпляра. В этом случае Date.now () по-прежнему выигрывает у new Date () и т.п., хотя только примерно на 20% в моем Chrome и на небольшую сумму в IE.

Смотрите мой JSPERF на

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

vs.

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

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

— СашаК
источник