Циклы действительно быстрее в обратном направлении?

Я слышал это довольно много раз. Действительно ли циклы JavaScript действительно быстрее при обратном отсчете? Если так, то почему? Я видел несколько примеров набора тестов, показывающих, что обратные циклы быстрее, но я не могу найти объяснения, почему!

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

Т.е.

for (var i = count - 1; i >= 0; i--)
{
  // count is only evaluated once and then the comparison is always on 0.
}

Это не так i--быстрее, чем i++. На самом деле, они оба одинаково быстры.

В восходящих циклах требуется время, чтобы оценить для каждого iразмер вашего массива. В этом цикле:

for(var i = array.length; i--;)

Вы оцениваете .lengthтолько один раз, когда вы объявляете i, тогда как для этого цикла

for(var i = 1; i <= array.length; i++)

Вы оцениваете .lengthкаждый раз i, когда вы увеличиваете , когда вы проверяете, если i <= array.length.

В большинстве случаев вам даже не стоит беспокоиться об этом виде оптимизации .

Этот парень сравнивал множество циклов в javascript, во многих браузерах. У него также есть набор тестов, так что вы можете запустить их самостоятельно.

Во всех случаях (если я не пропустил ни одного в моем чтении) самый быстрый цикл был:

var i = arr.length; //or 10
while(i--)
{
  //...
}

Я пытаюсь дать общую картину с этим ответом.

Следующие мысли в скобках были моей верой, пока я только недавно не проверил проблему:

[[В терминах языков низкого уровня, таких как C / C ++ , код скомпилирован так, что процессор имеет специальную команду условного перехода, когда переменная равна нулю (или не равна нулю).
Кроме того, если вам небезразлична такая большая оптимизация, вы можете пойти ++iвместо нее i++, потому что ++iэто однопроцессорная команда, а i++значит j=i+1, i=j.]]

По-настоящему быстрые петли можно сделать, развернув их:

for(i=800000;i>0;--i)
    do_it(i);

Это может быть намного медленнее, чем

for(i=800000;i>0;i-=8)
{
    do_it(i); do_it(i-1); do_it(i-2); ... do_it(i-7);
}

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

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

Следовательно, в JavaScript я бы предложил использовать что-то вроде

array.forEach(function(i) {
    do_it(i);
});

Это также менее подвержено ошибкам, и браузеры имеют возможность оптимизировать ваш код.

[ЗАМЕЧАНИЕ: не только браузеры, но у вас также есть место для легкой оптимизации, просто переопределите forEachфункцию (в зависимости от браузера), чтобы она использовала новейшие хитрости! :) @AMK говорит, что в особых случаях стоит использовать array.popor array.shift. Если вы сделаете это, положите его за занавес. Самое лишнее - добавить опции forEachдля выбора алгоритма зацикливания.]

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

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

Я провел более тщательную проверку, и оказалось, что в C / C ++, даже для операций 5e9 = (50,000x100,000), нет никакой разницы между повышением и понижением, если тестирование выполняется с константой, как говорит @alestanis. (Результаты JsPerf иногда противоречивы, но, по большому счету, говорят одно и то же: вы не можете иметь большого значения.)
Так --iчто это скорее «шикарная» вещь. Это только делает вас похожим на лучшего программиста. :)

С другой стороны, для разворачивания в этой ситуации 5e9 это снизило меня с 12 секунд до 2,5 секунд, когда я шел на 10 секунд, и до 2,1 секунд, когда я шел на 20 секунд. Это было без оптимизации, а оптимизация привела к невообразимому небольшому времени. :) (Развертывание может быть сделано моим способом выше или с использованием i++, но это не продвигает вещи вперед в JavaScript.)

В целом: сохраняйте i--/ i++и ++i/ или i++отличия от собеседований при приеме на работу, придерживайтесь array.forEachили выполняйте другие сложные библиотечные функции, если они доступны. ;)

i-- так быстро, как i++

Этот код ниже так же быстро, как ваш, но использует дополнительную переменную:

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

Рекомендуется НЕ оценивать размер массива каждый раз. Для больших массивов можно увидеть снижение производительности.

Поскольку вас интересует эта тема, взгляните на статью в блоге Грега Реймера о тесте цикла JavaScript. Какой самый быстрый способ кодирования цикла в JavaScript? :

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

Вы также можете выполнить тест производительности цикла , открыв https://blogs.oracle.com/greimer/resource/loop-test.html(не работает, если JavaScript заблокирован в браузере, например, с помощью NoScript ).

РЕДАКТИРОВАТЬ:

Более поздний тест, созданный Миланом Адамовским, можно выполнить здесь во время выполнения для разных браузеров.

Для тестирования в Firefox 17.0 на Mac OS X 10.6 я получил следующий цикл:

var i, result = 0;
for (i = steps - 1; i; i--) {
  result += i;
}

как самый быстрый предшествует:

var result = 0;
for (var i = steps - 1; i >= 0; i--) {
  result += i;
}

Это не --или ++, это операция сравнения. При этом --вы можете использовать сравнение с 0, а с ним ++нужно сравнить его с длиной. На процессоре сравнение с нулем обычно доступно, тогда как сравнение с конечным целым числом требует вычитания.

a++ < length

на самом деле составляется как

a++
test (a-length)

Таким образом, это занимает больше времени на процессоре при компиляции.

Короткий ответ

Для нормального кода, особенно в языке высокого уровня, таком как JavaScript , нет разницы в производительности i++и i--.

Критериями производительности является использование в forцикле и оператор сравнения .

Это относится ко всем языкам высокого уровня и в основном не зависит от использования JavaScript. Объяснение - полученный код ассемблера в нижней строке.

Детальное объяснение

Разница в производительности может возникнуть в цикле. Предпосылкой является то, что на уровне кода ассемблера вы можете видеть, что это compare with 0всего лишь один оператор, который не нуждается в дополнительном регистре.

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

for(var i = array.length; i--; )

будет оцениваться как псевдокод :

 i=array.length
 :LOOP_START
 decrement i
 if [ i = 0 ] goto :LOOP_END
 ... BODY_CODE
 :LOOP_END

Обратите внимание, что 0 является литералом или, другими словами, постоянным значением.

for(var i = 0 ; i < array.length; i++ )

будет оцениваться в псевдокод, подобный этому (предполагается нормальная оптимизация интерпретатора):

 end=array.length
 i=0
 :LOOP_START
 if [ i < end ] goto :LOOP_END
 increment i
 ... BODY_CODE
 :LOOP_END

Обратите внимание, что end является переменной, которая нуждается в регистре процессора . Это может вызвать дополнительный обмен регистров в коде и требует более дорогого оператора сравнения в ifоператоре.

Только мои 5 центов

Для языка высокого уровня удобочитаемость, которая облегчает ремонтопригодность, более важна как незначительное улучшение производительности.

Обычно классическая итерация от начала до конца массива лучше.

Более быстрая итерация от конца массива к началу приводит к возможно нежелательной обратной последовательности.

Пост скриптум

Как указано в комментарии: Разница --iи i--в оценке iдо или после уменьшения.

Лучшее объяснение - попробовать ;-) Вот пример Bash .

 % i=10; echo "$((--i)) --> $i"
 9 --> 9
 % i=10; echo "$((i--)) --> $i"
 10 --> 9

Я видел ту же рекомендацию в Sublime Text 2.

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

Например,

for (var i = 0; i < document.getElementsByTagName('li').length; i++)

намного медленнее чем

for (var i = 0, len = document.getElementsByTagName('li').length; i < len; i++)

С того места, где я стою, главное улучшение формы в вашем вопросе заключается в том, что она не объявляет дополнительную переменную ( lenв моем примере)

Но если вы спросите меня, все дело не в оптимизации i++против i--, а в том, что вам не нужно оценивать длину массива на каждой итерации (вы можете увидеть тест производительности на jsperf ).

Я не думаю, что имеет смысл говорить, что i--это быстрее, чем i++в JavaScript.

Прежде всего , это полностью зависит от реализации движка JavaScript.

Во-вторых , при условии, что простейшие конструкции с JIT'ом и переведены в нативные инструкции, тогда i++vs i--будет полностью зависеть от процессора, который его выполняет. То есть на ARM (мобильных телефонах) быстрее снижаться до 0, поскольку уменьшение и сравнение с нулем выполняются в одной инструкции.

Возможно, вы подумали, что один из них был напраснее другого, потому что предложенный способ

for(var i = array.length; i--; )

но предложенный способ не потому, что один быстрее, чем другой, а просто потому, что если вы пишете

for(var i = 0; i < array.length; i++)

затем на каждой итерации array.lengthнужно было оценить (возможно, более умный движок JavaScript мог выяснить, что цикл не изменит длину массива). Хотя это выглядит как простое утверждение, на самом деле это какая-то функция, которая вызывается скрытно движком JavaScript.

Другая причина, почему это i--можно считать «более быстрым», заключается в том, что движку JavaScript нужно выделить только одну внутреннюю переменную для управления циклом (переменная для var i). Если сравнивать с массивом array.length или какой-либо другой переменной, тогда для управления циклом требовалось более одной внутренней переменной, а количество внутренних переменных является ограниченным преимуществом движка JavaScript. Чем меньше переменных используется в цикле, тем больше у JIT шансов на оптимизацию. Вот почему i--можно считать быстрее ...

Поскольку ни один из других ответов, кажется, не отвечает на ваш конкретный вопрос (более половины из них показывают примеры C и обсуждают языки более низкого уровня, ваш вопрос касается JavaScript), я решил написать свой собственный.

Итак, поехали:

Простой ответ: i-- как правило, быстрее, потому что он не должен запускать сравнение с 0 при каждом запуске, результаты теста для различных методов приведены ниже:

Результаты теста: как доказал этот jsPerf, arr.pop()на самом деле это самый быстрый цикл. Но, сосредоточив внимание на --i, i--, i++и , ++iкак вы просили в вашем вопросе, вот JSPerf (они от множества JSPerf, смотрите , пожалуйста , источники ниже) ; результаты суммированы:

--iи i--то же самое в Firefox, пока i--быстрее в Chrome.

В Chrome основного цикла ( for (var i = 0; i < arr.length; i++)) быстрее , чем i--и в --iто время как в Firefox это медленнее.

И в Chrome, и в Firefox кэширование arr.lengthзначительно быстрее, а Chrome опережает его примерно на 170 000 операций в секунду.

Без существенной разницы, ++iбыстрее, чем i++в большинстве браузеров, AFAIK, это никогда не бывает наоборот в любом браузере.

Короткое резюме: arr.pop() самая быстрая петля на сегодняшний день; для специально упомянутых циклов, i--это самый быстрый цикл.

Источники: http://jsperf.com/fastest-array-loops-in-javascript/15 , http://jsperf.com/ipp-vs-ppi-2

Надеюсь, это ответит на ваш вопрос.

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

В некоторых случаях доступ к членам массива в порядке столбцов происходит быстрее, чем в строке, из-за увеличения коэффициента попадания.

В последний раз я беспокоился об этом, когда писал сборку 6502 (8-битная, да!). Большим преимуществом является то, что большинство арифметических операций (особенно декременты) обновляли набор флагов, одним из которых был Zиндикатор «достигнут нуля».

Итак, в конце цикла вы просто выполнили две инструкции: DEC(уменьшение) и JNZ(переход, если не ноль), сравнение не требуется!

Это можно объяснить тем, что JavaScript (и все языки) в конечном итоге превращаются в коды операций для работы на процессоре. Процессоры всегда имеют одну инструкцию для сравнения с нулем, что чертовски быстро.

Кроме того, если вы можете гарантировать countвсегда >= 0, вы можете упростить:

for (var i = count; i--;)
{
  // whatever
}

Это не зависит от знака --или ++, но зависит от условий, которые вы применяете в цикле.

Например: ваш цикл будет быстрее, если переменная имеет статическое значение, чем если бы ваш цикл проверял условия каждый раз, например длину массива или другие условия.

Но не беспокойтесь об этой оптимизации, потому что на этот раз ее эффект измеряется в наносекундах.

for(var i = array.length; i--; )не намного быстрее. Но когда вы заменяете array.lengthна super_puper_function(), это может быть значительно быстрее (так как он вызывается на каждой итерации). В этом разница.

Если вы собираетесь изменить его в 2014 году, вам не нужно думать об оптимизации. Если вы собираетесь изменить его с помощью функции «Поиск и замена», вам не нужно думать об оптимизации. Если у вас нет времени, вам не нужно думать об оптимизации. Но теперь у вас есть время подумать об этом.

PS: i--не быстрее чем i++.

Короче говоря: в JavaScript нет абсолютно никакой разницы.

Прежде всего, вы можете проверить это самостоятельно:

• jsperf - отличная платформа для всех видов тестирования производительности в JavaScript .

• http://jsperf.com/inc-vs-dec-2

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

Итак, насколько вы можете видеть, нет никакой разницы между производительностью в любой среде.

Если вы хотите улучшить производительность вашего скрипта, попробуйте сделать следующее:

1. Сделайте var a = array.length;заявление, чтобы вы не вычисляли его значение каждый раз в цикле
2. Сделайте раскрутку цикла http://en.wikipedia.org/wiki/Loop_unwinding

Но вы должны понимать, что улучшение, которое вы можете получить, будет настолько незначительным, что в большинстве случаев вы даже не будете беспокоиться об этом.

Мое собственное мнение, почему появилось такое заблуждение (Dec против Inc)

Давным-давно была общая машинная инструкция, DSZ (Decrement и Skip on Zero). Люди, которые программировали на ассемблере, использовали эту инструкцию для реализации циклов, чтобы сохранить регистр. Теперь эти древние факты устарели, и я уверен, что вы не получите никакого улучшения производительности ни на одном языке, используя это псевдо улучшение.

Я думаю, что единственный способ распространения таких знаний в наше время - это когда вы читаете чужой код. Посмотрите на такую ​​конструкцию и спросите, почему она была реализована, и вот ответ: «это улучшает производительность, потому что она сравнивается с нулем». Вы растерялись из-за высшего знания своего коллеги и думаете использовать его, чтобы быть намного умнее :-)

Я сделал сравнение на jsbench .

Как указывал Алестани, в восходящих циклах требуется время, чтобы оценить для каждой итерации размер вашего массива. В этом цикле:

for ( var i = 1; i <= array.length; i++ )

Вы оцениваете .lengthкаждый раз, когда увеличиваете i. В этом:

for ( var i = 1, l = array.length; i <= l; i++ )

Вы оцениваете .lengthтолько один раз, когда заявляете i. В этом:

for ( var i = array.length; i--; )

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

Цикл с вызовом функции (определяется в другом месте):

for (i = values.length; i-- ;) {
  add( values[i] );
}

Цикл с встроенным кодом:

var sum = 0;
for ( i = values.length; i-- ;) {
  sum += values[i];
}

Если вы можете встроить свой код вместо вызова функции, не жертвуя удобочитаемостью, вы можете сделать цикл на порядок быстрее!

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

1. Узкое место может быть в другом месте (ajax, reflow, ...)
2. Вы можете выбрать лучший алгоритм
3. Вы можете выбрать лучшую структуру данных

Но помните:

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

То, как вы делаете это сейчас, не быстрее (кроме того, что это неопределенный цикл, я думаю, вы хотели это сделать i--.

Если вы хотите сделать это быстрее, сделайте:

for (i = 10; i--;) {
    //super fast loop
}

Конечно, вы не заметите это на такой маленькой петле. Причина в том, что он быстрее, потому что вы уменьшаете значение i, проверяя, что оно «true» (оно оценивается как «false», когда достигает 0)

Иногда внесение очень незначительных изменений в способ написания нашего кода может существенно повлиять на скорость выполнения нашего кода. Одна область, где незначительное изменение кода может иметь большое значение для времени выполнения, это где у нас есть цикл for, который обрабатывает массив. Если массив состоит из элементов на веб-странице (например, переключателей), изменение имеет наибольший эффект, но все же стоит применить это изменение, даже если массив является внутренним по отношению к коду Javascript.

Обычный способ кодирования цикла for для обработки массива lis выглядит следующим образом:

for (var i = 0; i < myArray.length; i++) {...

Проблема в том, что для оценки длины массива с использованием myArray.length требуется время, а способ, которым мы закодировали цикл, означает, что эта оценка должна выполняться каждый раз вокруг цикла. Если массив содержит 1000 элементов, то длина массива будет оценена 1001 раз. Если бы мы смотрели на переключатели и имели myForm.myButtons.length, то это займет еще больше времени для оценки, так как соответствующая группа кнопок в указанной форме должна сначала быть найдена, прежде чем длина может быть оценена каждый раз вокруг цикла.

Очевидно, что мы не ожидаем, что длина массива изменится во время его обработки, поэтому все эти пересчеты длины просто без необходимости прибавляют время обработки. (Конечно, если у вас есть код внутри цикла, который добавляет или удаляет записи массива, то размер массива может меняться между итерациями, и поэтому мы не можем изменить код, который проверяет его)

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

Код для этого:

for (var i = 0, var j = myArray.length; i < j; i++) {...

Итак, теперь мы только один раз оцениваем размер массива и проверяем наш счетчик цикла по переменной, которая каждый раз хранит это значение в цикле. Эта дополнительная переменная может быть доступна гораздо быстрее, чем оценка размера массива, поэтому наш код будет работать намного быстрее, чем раньше. У нас просто есть одна дополнительная переменная в нашем скрипте.

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

Последний код, который обрабатывает наш массив наиболее эффективным способом:

for (var i = myArray.length-1; i > -1; i--) {...

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

++vs. --не имеет значения, потому что JavaScript - это интерпретируемый язык, а не скомпилированный язык. Каждая инструкция переведена на более чем один машинный язык, и вы не должны заботиться о кровавых деталях.

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

Вы должны написать читабельный код.

Во многих случаях это, по сути, не имеет ничего общего с тем, что процессоры могут сравниваться с нулем быстрее, чем другие сравнения.

Это потому, что только несколько движков Javascript (те, что в списке JIT) фактически генерируют код машинного языка.

Большинство движков Javascript создают внутреннее представление исходного кода, которое они затем интерпретируют (чтобы понять, на что это похоже, посмотрите в нижней части этой страницы на SpiderMonkey в Firefox ). Обычно, если фрагмент кода делает практически то же самое, но приводит к более простому внутреннему представлению, он будет работать быстрее.

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

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

В низкоуровневой сборке есть инструкция зацикливания, которая называется DJNZ (уменьшить и перейти, если не ноль). Таким образом, декремент и переход - все в одной инструкции, что делает его, возможно, немного быстрее, чем INC и JL / JB (увеличение, переход, если меньше, чем / прыжок, если ниже). Кроме того, сравнение с нулем проще, чем сравнение с другим числом. Но все это действительно маргинально, а также зависит от целевой архитектуры (может иметь значение, например, от Arm в смартфоне).

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

Он используется , чтобы сказать , что --i был быстрее (в C ++) , потому что есть только один результат, уменьшенное значение. i-- необходимо сохранить уменьшенное значение обратно в i, а также сохранить исходное значение в качестве результата (j = i--;). В большинстве компиляторов это использовало два регистра, а не один, что могло привести к тому, что другая переменная должна была быть записана в память, а не сохранена как переменная регистра.

Я согласен с теми, кто сказал, что в эти дни нет никакой разницы.

Очень простыми словами

«i-- и i ++. На самом деле, они оба занимают одно и то же время».

но в этом случае, когда у вас есть инкрементная операция .. процессор оценивает .length каждый раз, когда переменная увеличивается на 1, а в случае уменьшения .. особенно в этом случае, он будет оценивать .length только один раз, пока мы не получим 0.

Во-первых, i++и i--занимайте ровно столько же времени на любом языке программирования, включая JavaScript.

Следующий код занимает много разного времени.

Быстро:

for (var i = 0, len = Things.length - 1; i <= len; i++) { Things[i] };

Медленный:

for (var i = 0; i <= Things.length - 1; i++) { Things[i] };

Поэтому следующий код тоже занимает другое время.

Быстро:

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

Медленный:

for (var i = 0; i <= Things.length - 1; i++) { Things[i] };

PS Slow является медленным только для нескольких языков (движки JavaScript) из-за оптимизации компилятора. Лучший способ - использовать «<» вместо «<=» (или «=») и «--i» вместо «i--» .

Не много времени тратится на i- или i ++. Если вы углубитесь в архитектуру ЦП, то она ++будет более быстрой, чем операция --, поскольку --операция будет дополнять 2, но происходит внутри аппаратного обеспечения, так что это будет быстрым, и между этими операциями не будет существенной разницы, ++а --также эти операции считаются Наименьшее время, затрачиваемое на процессор.

Цикл for работает так:

• Инициализируйте переменную один раз в начале.
• Проверьте ограничение во втором операнде петли, <, >, <=и т.д.
• Затем примените цикл.
• Увеличивайте цикл и снова запускайте эти процессы.

Так,

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

вычислит длину массива только один раз в начале, и это не много времени, но

for(var i = array.length; i--; ) 

рассчитает длину в каждом цикле, так что это займет много времени.

Лучший подход к ответу на подобные вопросы - это попробовать. Установите цикл, который насчитывает миллион итераций или что-то еще, и делайте это в обоих направлениях. Время оба цикла, и сравнить результаты.

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

Люблю это, много оценок, но нет ответа: D

Проще говоря сравнение с нулем всегда самое быстрое сравнение

Так что (a == 0) на самом деле быстрее возвращает True, чем (a == 5)

Он маленький и незначительный, и из 100 миллионов строк в коллекции его можно измерить.

то есть в цикле вы могли бы сказать, где я <= array.length и увеличивая я

в нисходящем цикле вы можете говорить, где i> = 0, и вместо этого уменьшать i.

Сравнение происходит быстрее. Не «направление» петли.

ПОМОГИТЕ ДРУГИМ ИЗБЕГАТЬ ГОЛОВНОЙ БУКВЫ --- ПРОЧИТАЙТЕ ЭТО!

Самый популярный ответ на этой странице не работает для Firefox 14 и не проходит через jsLinter. Для циклов while требуется оператор сравнения, а не присваивание. Это работает на хром, сафари и даже т.е. Но умирает в Firefox.

СЛОМАНО!

var i = arr.length; //or 10
while(i--)
{
  //...
}

ЭТО БУДЕТ РАБОТАТЬ! (работает на firefox, передает jsLinter)

var i = arr.length; //or 10
while(i>-1)
{
  //...
  i = i - 1;
}

Это всего лишь предположение, но, возможно, это потому, что процессору проще сравнивать что-либо с 0 (i> = 0), а не с другим значением (i <Things.length).