Используй forEach и проч. когда удобно. Если производительность упрётся именно в этом месте - всегда можно будет переписать циклом. Но скорее всего этого никогда не понадобится.)

Antonius, если писать код руководствуясь только скоростью работы, то получится трудно-поддерживаемая груда кода. Кроме того, разные варианты отрабатывают в разных браузерах по-разному, или даже в разных версиях одного браузера.

Да, приходится постоянно балансировать между читаемостью/поддерживаемостью и скоростью.

Однако в браузерах, доступных мне (okouser, это последние версии) тест http://jsperf.com/for-vs-foreach/111 показывает проигрыш forEach, в разной степени, иногда с небольшой разницей, иногда с внушительной, но он медленнее.

Кстати, да, еще можно руководствоваться такими соображениями — если действия, выполняемые в каждой итерации цикла, достаточно «дорогие» по производительности, то накладные расходы на организацию самого обхода массива существенного влияния на время выполнения не окажут.

okouser, по сути если нужно обработать массив на пару тысяч элементов то лучше использовать for (что вообще не является хорошо:)), а так разница в пару милесекунд http://jsfiddle.net/eT25E/

Я в своё время заморочился, и написал свою реализацию forEach с JIT компиляцией, по скорости равна циклам.

kobezzza, поделишься?)

Откройте секрет, как можно со стороны скрипта влиять на JIT?

Как закончу работу над Snakeskin, то опубликую (там кое что допилить надо ещё и тестов понаписать).

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

Ждем января, значит :) Не пропустить бы.