Это - более быстрый доступ массив JavaScript непосредственно?

«Мы должны забыть о небольшой эффективности, скажем, примерно в 97% случаев: преждевременная оптимизация - корень всех зол».

- Дональд Кнут

Лично Я бы использовал ваш способ, потому что он более читабельный и более простой в обслуживании. Затем я бы использовал такой инструмент, как YSlow , чтобы профилировать код и устранить узкие места в производительности.

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

var p;
var ps = document.getElementsByTagName("P");

for (var i = 0; (p=ps[i]); i++) {
  //...
}

Конечно, это также предполагает, что ни одно из значений в вашем массиве не оценивается как «false». Числовой массив, который может содержать 0, прервет этот цикл.

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

Вопрос в том ... какие накладные расходы? Достаточно ли о чем беспокоиться? Я не сторонник преждевременной оптимизации. Однако это интересный случай, потому что затронуты не только затраты на итерацию, но и дополнительные накладные расходы, поскольку NodeList должен синхронизироваться с любыми изменениями в DOM.

Без дополнительных доказательств я склонен верить статье.

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

Идеальный цикл был бы следующим:

nl = document.getElementsByTagName("P");

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

EDIT: Я фактически протестировал эти два примера, которые вы привели в Firebug, используя console.time, и, как и все, хотя первый занял 1 мс, а второй - 0 мс =)

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

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

Обычно я делаю это (перемещаю тест длины за пределы цикла for)

var nl = document.getElementsByTagName("p");
var nll = nl.length;
for(var i=0;i<nll;i++){
    p = nl[i];
}

или для компактности ...

var nl = document.getElementsByTagName("p");
for(var i=0,nll=nl.length;i<nll;i++){
    p = nl[i];
}

, который предполагает, что длина не изменяется во время доступа (что в в моих случаях - нет)

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

Автор статьи писал:

В большинстве случаев это быстрее, чем кеширование NodeList. Во втором примере браузеру не нужно создавать объект списка узлов. Ему нужно только найти элемент с индексом i в этот точный момент.

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

Из статьи, на которую вы ссылаетесь:

Во втором примере браузеру не нужно создавать объект списка узлов. Ему нужно только найти элемент с индексом i в этот самый момент.

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

Во втором примере, отнюдь не нужно создавать список узлов, браузер должен создать список узлов каждый раз через цикл найти элемент с индексом i. Тот факт, что ссылка на список узлов никогда не присваивается переменной, не означает Это значит, что список не нужно создавать, как, кажется, думает автор. Создание объектов обходится дорого (независимо от того, что автор говорит о том, что браузеры «оптимизированы для этого»), так что это будет большим ударом по производительности для многих приложений.

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

(Честно говоря, я тоже не знаю. не доверяю совету программиста, который использует имя переменной вроде "