Улучшают ли новые браузеры для циклов?

Я читал Николаса Зацкаса Высокопроизводительный Javascript, в котором он обсуждает оптимизацию цикла for, меняя его и сводя к минимуму поиск свойств.

Вместо:

for (var i = 0; i < items.length; i++ ) {
  processItems(items[i]);
}

Вы получаете:

for (var i = items.length; i--; ) {
  processItems(items[i]);
}

На момент написания, время исполнения было "до 50% -60% быстрее оригинала". Тем не менее я создал jsperf, а в Firefox и Chrome я заметил, что оптимизированный для цикла на самом деле заметно медленнее, особенно в Firefox.

enter image description here

Улучшают ли новые браузеры для циклов по-разному? Самый эффективный способ написать цикл for теперь просто базовым способом?

Ответы

Ответ 1

Возможно, вы могли бы также включить тестовый сценарий, а не заставлять браузер отбрасывать ответ на логический?

var i, arr = [...];
for (i = arr.length; i > 0; i -= 1) { arr[i-1] = 1; }

Во-первых, ваш цикл отличает 0 как конечное условие, во-вторых, arr[i], где i = arr.length - undefined, что означает, что Chrome будет деинфицировать цикл в отношении доступа к этому массиву из-за неявные типы, под капотом Chrome.

Итак, теперь, что касается Chrome, у вас есть две большие деоптимизации, происходящие в прецеденте Zakas.

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

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