Почему array.push иногда быстрее, чем массив [n] = значение?

Все виды факторов играют роль, большинство реализаций JS использует плоскую антенную решетку, которая преобразовывает в редкое устройство хранения данных, если это становится необходимым позже.

В основном решение стать редким является эвристикой на основе того, какие элементы устанавливаются, и сколько пространства было бы потрачено впустую, чтобы остаться плоским.

В Вашем случае Вы устанавливаете последний элемент сначала, что означает, что механизм JS будет видеть массив, который должен иметь длину n, но только единственный элемент. Если n будет достаточно большим, то это сразу сделает массив разреженным массивом - в большинстве механизмов, это означает, что все последующие вставки возьмут медленный случай разреженного массива.

необходимо добавить дополнительный тест, в котором Вы заполняете массив от индекса 0 до индекса n-1 - это должно быть очень, намного быстрее.

В ответ на @Christoph и из требования отложить, вот описание того, как массивы (обычно) реализуются в JS - специфические особенности варьируются с механизма JS на механизм JS, но общий принцип является тем же.

Весь JS Object с (так не строки, числа, верные, ложные, undefined, или null), наследовались типу базового объекта - точная реализация варьируется, это могло быть наследование C++, или вручную в C (существуют преимущества для выполнения в нем так или иначе) - тип базового объекта определяет методы доступа свойства по умолчанию, например,

interface Object {
    put(propertyName, value)
    get(propertyName)
private:
    map properties; // a map (tree, hash table, whatever) from propertyName to value
}

, Этот Тип объекта обрабатывает всю стандартную логику доступа свойства, опытную цепочку, и т.д. Тогда реализация Массива становится

interface Array : Object {
    override put(propertyName, value)
    override get(propertyName)
private:
    map sparseStorage; // a map between integer indices and values
    value[] flatStorage; // basically a native array of values with a 1:1
                         // correspondance between JS index and storage index
    value length; // The `length` of the js array
}

Теперь при создании Массива в JS, механизм создает что-то сродни вышеупомянутой структуре данных. Когда Вы вставляете объект в экземпляр Массива помещенные проверки метода Массива, чтобы видеть, является ли имя свойства целым числом (или может быть преобразован в целое число, например, "121", "2341", и т.д.) между 0 и 2^32-1 (или возможно 2^31-1, я забываю точно). Если это не, то помещенный метод передается реализации базового объекта, и стандартная [[Помещенная]] логика сделана. Иначе значение помещается в собственное устройство хранения данных Массива, если данные будут достаточно компактны тогда, то механизм будет использовать устройство хранения данных плоской антенной решетки, в этом случае вставка (и извлечение) является просто стандартной операцией индексации массива, иначе механизм преобразует массив в редкое устройство хранения данных и поместит/получит, используют карту для получения от propertyName для оценки местоположения.

я честно не уверен, преобразовывает ли какой-либо механизм JS в настоящее время с редкого на плоское устройство хранения данных после того, как то преобразование происходит.

Anyhoo, это - обзор довольно высокого уровня того, что происходит и не учитывает много более неприглядных деталей, но это - общий шаблон реализации. Специфические особенности того, как дополнительное устройство хранения данных, и как помещал/получал, диспетчеризируется, отличаются с механизма на механизм - но это является самым ясным, я могу действительно описать дизайн/реализацию.

А незначительная дополнительная точка, в то время как спецификация ES относится к propertyName как строка механизмы JS, имеет тенденцию специализироваться на целочисленных поисках также, таким образом someObject[someInteger] не преобразует целое число в строку, если Вы посмотрите на объект, который имеет целочисленные свойства, например, Массив, Строку и типы DOM (NodeList с, и т.д.).