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

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

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

т. е.

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

30 ответов


дело не в этом 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);
});

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

[примечание: не только браузеры, но у вас тоже есть пространство для оптимизации, просто переопределите the forEach функция (браузер зависимо), так что он использует последнюю лучшую хитрость! :) @A. M. K. говорит, что в особых случаях стоит использовать array.pop или array.shift. Если вы это сделаете, положите его за занавеску. The возможное перебор добавить опции в forEach для выбора алгоритма цикла.]

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

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

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

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

всего: keep 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).

EDIT:

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

на тестирование в 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;
}

Benchmark example.


это не -- или ++, это операция сравнения. С -- вы можете использовать сравнение с 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

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

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

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

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

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

Post scriptum

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

лучшее объяснение, чтобы попробовать его; -) вот Баш пример.

 % 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++ vs i-- оптимизация, но о том, чтобы не оценивать длину массива на каждой итерации (вы можете увидеть тестовый тест на см. Этот тест jsperf).


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

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

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

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

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

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

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

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

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


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

так, вот так:

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

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

--i и i-- одинаковы в Firefox в то время как i-- быстрее в Chrome.

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

в Chrome и Firefox кэшируются arr.length значительно быстрее с Chrome впереди около 170,000 ops / sec.

без существенной разницы, ++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 нет абсолютно никакой разницы.

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

если вы собираетесь изменить его в 2014 году, вам не нужно думать об оптимизации. Если вы собираетесь изменить его с помощью "Search & Replace", вам не нужно думать об оптимизации. Если у вас нет времени, вам не нужно думать об оптимизации. Но теперь у тебя есть время подумать. об этом.

П. С.: i-- не быстрее, чем i++.


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

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

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

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

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

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

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

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

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

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

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

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

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


я сравнение на 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];
}

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


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

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

но помните:

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


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

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

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

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


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

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

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

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


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

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

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


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

Я согласен с теми, кто сказал, что это не имеет значения эти дни.


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

"Я-и я++. На самом деле, они оба одинаково".

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


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

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

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


во-первых,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] };

П. С. медленно медленный только для нескольких языков (движков JavaScript) из-за оптимизации компилятора. Лучший способ-использовать ' (или '=') и


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

на цикл работает как это:

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

и

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

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

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

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


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

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


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

просто поставить сравнение с нулем всегда самое быстрое сравнение

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

Это маленький и незначительный и с 100 миллионов строк в коллекции это измеримо.

i.e в цикле вы можете сказать, где I

на петле вниз вы можете сказать, где i >= 0 и быть вместо этого я решил.

сравнение быстрее. Не "направление" петли.


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

самый популярный ответ на этой странице не работает для Firefox 14 и не проходит jsLinter. циклам" while " нужен оператор сравнения, а не назначение. Он работает на chrome, safari и даже ie. Но умирает в 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