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

var timeInMs = Date.now();

per MDN

против.

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

per MDN.

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

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

Ответ 1

Все эти вещи одинаковы (редактирование семантически, производительность немного лучше с .now()):

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

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

var now = new Date();

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

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

против.

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

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