для
forпетли намного эффективнее. Это конструкция цикла, специально разработанная для итерации, пока условие истинно , и в то же время предлагает пошаговый механизм (обычно для увеличения итератора). Пример:
for (var i=0, n=arr.length; i < n; ++i ) {
...
}
Это не означает, что for -loops всегда будет более эффективным, просто JS-движки и браузеры оптимизировали их для этого. На протяжении многих лет возникали компромиссы в отношении того, какая конструкция цикла более эффективна (для while, reduce, reverse-while и т. Д.) - разные браузеры и JS-движки имеют свои собственные реализации, которые предлагают разные методологии для получения тех же результатов. По мере дальнейшей оптимизации браузеров для удовлетворения требований к производительности, теоретически [].forEachможно было бы реализовать его таким образом, чтобы он был быстрее или сопоставим с for.
Преимущества:
- эффективный
- раннее завершение цикла (почести
breakи continue)
- контроль состояния (
i<nможет быть любым, не привязанным к размеру массива)
- переменная область видимости (
var iостается iдоступной после завершения цикла)
для каждого
.forEach- это методы, которые в основном перебирают массивы (также и другие перечисляемые объекты , такие как Mapи Setобъекты). Они новее и содержат код, который субъективно легче читать. Пример:
[].forEach((val, index)=>{
...
});
Преимущества:
- не требует настройки переменных (перебирает каждый элемент массива)
- functions / arrow-functions охватывают переменную блоком.
В приведенном выше примере valэто будет параметр вновь созданной функции. Таким образом, любые переменные, вызываемые valдо цикла, сохранят свои значения после его завершения.
- субъективно более удобен в обслуживании, поскольку может быть легче определить, что делает код - он выполняет итерацию по перечислимому; тогда как цикл for может использоваться для любого количества схем цикла
Производительность
Производительность - непростая тема, которая обычно требует некоторого опыта, когда дело касается предусмотрительности или подхода. Чтобы заранее (при разработке) определить, какой объем оптимизации может потребоваться, программист должен иметь хорошее представление о прошлом опыте работы с проблемным случаем, а также хорошее понимание потенциальных решений.
Использование jQuery в некоторых случаях может быть слишком медленным временами (опытный разработчик может знать об этом), тогда как в других случаях может быть не проблема, и в этом случае совместимость библиотеки с кросс-браузером и простота выполнения других функций (например, AJAX, обработка событий) будет стоить сэкономленного времени на разработку (и обслуживание).
Другой пример: если бы производительность и оптимизация были всем, не было бы другого кода, кроме машинного или сборочного. Очевидно, что это не так, поскольку существует множество различных языков высокого и низкого уровня, каждый из которых имеет свои собственные компромиссы. Эти компромиссы включают в себя, помимо прочего, специализацию, простоту и скорость разработки, простоту и скорость обслуживания, оптимизированный код, код без ошибок и т. Д.
Подходить
Если у вас нет четкого представления о том, что для чего-то потребуется оптимизированный код, как правило, рекомендуется сначала написать поддерживаемый код. Оттуда вы можете протестировать и определить, что требует большего внимания, когда это необходимо.
Тем не менее, некоторые очевидные оптимизации должны быть частью общей практики и не требовать никаких размышлений. Например, рассмотрим следующий цикл:
for (var i=0; i < arr.length; ++i ){}
Для каждой итерации цикла JavaScript arr.lengthизвлекает операции расчета стоимости поиска ключа в каждом цикле. Нет причин, по которым этого не должно быть:
for (var i=0, n=arr.length; i < n; ++i){}
Это делает то же самое, но извлекается только arr.lengthодин раз, кэшируя переменную и оптимизируя ваш код.