Любое обращение к DOM - обычно тяжелее для браузера, чем обращение к переменной javascript. Изменение свойств, влияющих на отображение элемента: className, style, innerHTML и ряда других - особенно сложные операции.
Рассмотрим функцию, которая проходит всех детей узла и ставит им свойства:
function testAttachClick(parent) {
var elements = parent.getElementsByTagName('div')
for(var i=0; i<elements.length; i++) {
elements[i].onclick = function() {
alert('click on '+this.number)
}
elements[i].number = i
}
}
Сколько в ней обращений к DOM ?
Правильный ответ - 4 обращения.
Первое - самое очевидное:
var elements = parent.getElementsByTagName('div')
Функция getElementsByTagName() возвращает специальный объект NodeList, который похож на массив: есть длина и нумерованы элементы, но на самом деле это динамический объект DOM.
Например, если один из элементов NodeList будет вдруг удален из документа, то он пропадет и из elements.
Поэтому следующие обращения - тоже работают с DOM, причем на каждой итерации цикла:
function testAttachClick2(parent) {
var elements = parent.getElementsByTagName('div')
var len = elements.length
var elem
for(var i=0; i<len; i++) {
elem = elements[i]
elem.onclick = function() {
alert('click on '+this.number)
}
elem.number = i
}
}
Такая оптимизация полезна и в случае, когда elements - обычный массив, но эффект от уменьшения обращений к DOM NodeList гораздо сильнее.
Рассмотрим заодно еще небольшую оптимизацию. Функция, которая назначается onclick внутри цикла - статическая. Вынесем ее вовне цикла:
function testAttachClick3(parent) {
var elements = parent.getElementsByTagName('div')
var len = elements.length
var elem
var handler = function() {
alert('click on '+this.number)
}
for(var i=0; i<len; i++) {
elem = elements[i]
elem.onclick = handler
elem.number = i
}
}
Например, из массива данных делается HTML-таблица:
function makeTable() {
var s = '<table><tr>'
for(var i=0; i<arrayData.length; i++) {
s += '<td>' + arrayData[i] + '</td>'
}
s+='</tr></table>'
return s
}
По-видимому, каждый раз при сложении строк:
создается новая строка
туда копируется первая строка
далее копируется вторая строка
Хотя правильно было бы просто приписывать вторую строку к первой. Тут есть некоторые сложности на низком уровне - в работе с памятью и т.п, но они вполне преодолимы.
В некоторых языках предусмотрены специальные классы для сложения многих строк в одну. Например, в Java это StringBuilder.
Соответствующий прием в javascript - сложить все куски в массив, а потом - получить длинную строку вызовом Array#join.
Так будет выглядить оптимизированный пример с таблицей:
function makeTable2() {
var buffer = []
for(var i=0; i<arrayData.length; i++) {
buffer.push(arrayData[i])
}
var s = '<table><tr><td>' + buffer.join('</td><td>') + '</td></tr></table>'
return s
}
В этом тесте таблица делается из 150 ячеек данных, т.е всего примерно 150 операций прибавления строки к создаваемой таблице.
Тормоза на строках отчетливо видны в Internet Explorer.
Время makeTable
Время makeTable2
В тех браузерах, где проблем со строками нет, заполнение массива является лишней операцией и общее время, наоборот, увеличивается.
Тем не менее, этот способ оптимизации можно применять везде, т.к он уменьшает максимальное время выполнения (IE).
И, конечно, конструирование через строки работает быстрее создания таблицы через DOM, когда каждый элемент делается document.createElement(..).
Только вот таблицу надо делать целиком, т.к в Internet Explorer свойство innerHTML работает только на самом нижнем уровне таблицы: TD, TH и т.п, и не работает для TABLE, TBODY, TR...
В IE есть такая интересная штука как CSS-expressions.
Как правило они используются для обхода IEшных недостатков и багов в верстке. Например:
p {
max-width:800px;
width:expression(document.body.clientWidth > 800? "800px": "auto" );
}
Идея хорошая, спору нет, это работает. Но есть здесь и подводный камень.
CSS expressions вычисляются при каждом событии, включая движение мыши, скроллинг окна и т.п.
Например, посмотрите эту страничку в Internet Explorer - полоса чуть ниже должна быть частично закрашена. Каждые 10 вычислений CSS expression меняют ее ширину на 1.
Клик на полоске покажет, сколько всего раз вычислилось CSS expression.
Если CSS-expression достаточно сложное, например, включает вложенные Javascript-вызовы для определения размеров элементов, то передвижение курсора может стать "рваным", как и при сложном обработчике onmousemove.
function buildUI2(parent) {
var elementText = ''
elementText += buildTitle()
elementText += buildBody()
elementText += buildFooter()
parent.innerHTML = elementText
}
Это не всегда удается сделать, так как может придется менять не только innerHTML. Может быстрее будет удаление из документа узла средством removeChild() затем создание нового или изменение старого объекта, и в конце appendChild() ?
А теперь внимание!!!
Обнаружил падение скорости у себя в проекте. в итоге обнаружил
что Array.join - с большими строками (под 2-10кб) работает отвратительно под всеми браузерами.
а стандартная конктатенация через '+' - работает.... на 4 порядка быстрее!!! под IE8, и 3 порядка под FF3.6
Можете протестировать.
console.log(new Date().getTime());
q='';
for (var i=0; i < 2500; i++) {
q += 'dsfkbjdkvbnfdkwlfbgnmdekwlq;edfgnmdekwlq;dfgnemwlq;sdfbjnvmdls;afkbnmvd,lsfkbnjfdmsla';
}
console.log(new Date().getTime());
console.log(new Date().getTime());
q='';
for (var i=0; i < 2500; i++) {
q = [q, 'dsfkbjdkvbnfdkwlfbgnmdekwlq;edfgnmdekwlq;dfgnemwlq;sdfbjnvmdls;afkbnmvd,lsfkbnjfdmsla'].join('');
}
console.log(new Date().getTime());
Вы просто очень неэффективно записали второй цикл, нужно так:
q=[];
for (var i=0; i < 2500; i++) {
q.push('dsfkbjdkvbnfdkwlfbgnmdekwlq;edfgnmdekwlq;dfgnemwlq;sdfbjnvmdls;afkbnmvd,lsfkbnjfdmsla');
}
q.join('');
В этом варианте на моей машине при 25000 итерациях второй вариант проигрывает первому 2-3 миллисекунды в FF и Opera. В IE второй вариант вдвое эффективнее.
Главное чтобы подобные оптимизации не оказались экономией на спичках, прежде всего нужно писать грамотный и понятный код, а оптимизировать в тех случаях, когда производительность действительно снижается настолько, что это заметно человеческому глазу.
Да возможно, но чем тогда объясняется, данный проигрыш второго варианта?
И, ИМХО, конструкция с push не самая эффективная, быстрее должно быть так.
q[q.length] = 'fdfdfd';
Хотя бы тем, что вы в качестве индекса используете обращение к изменяемому свойству, это из разряда оптимизации описанной в «Более сложном примере», судя по всему.
[code]var s = '' + buffer.join('') + ''[/code]
Метод довольно быстрый, спору нет, что подтверждает вот этот Benchmark.
В процессе работы над проектом возник вопрос, а как правильно создавать таблицу с произвольным количеством столбцов? В моем случае приходится применять цикл. Как грамотнее в этом случае оптимизировать код?
У меня получается пока три шага:
На первом я формирую заголовки столбцов по принципу метода join " ... "
[code]var titleTable = "" + row_buffer.join('') + '\n';[/code]
А вот на втором надо сформировать основное тело таблицы в зависимости от кол-ва столбцов. И вот тут возникает вопрос. Каков самый оптимизированный метод из существующих?
"Рассмотрим заодно еще небольшую оптимизацию. Функция, которая назначается onclick внутри цикла - статическая. Вынесем ее вовне цикла:"
Кто-нибудь может объяснить, почему вынос функции так сильно влияет на скорость выполнения? И что происходит внутри, когда мы выносим функцию таким образом?
Некоторые оптимизации при проверке на Google Chrome приводят к совершенно обратным результатам. Для ИЕ и ФФ -- да, все работает. Так что аккуратно использовать надо.
Все с вопросом разобрался, скорей всего алгоритм сложения строк изменился в современных браузерах и теперь при конкатенации не создается новая строка. в отличии от старого осла, так что теперь теперь конткатенация строк быстрей чем вариант с джоином
Хорошая статья.
Позновательная. Надо будет применить...
Да, полезно. Даже и не думал, что "CSS expressions вычисляются при каждом событии"...
А в Safari 3.0.2 (522.13.1) первый тест (buildUI) вообще около 1200 мс выполняется... не ожиданно так... в ишаке и то в 3 раза быстрее...
наверное стоит также упомянуть и о нативных функциях / операторах, при хитром использовании которых можно добиться более высокой производительности (
, избегание while, Array#push, и так далее)
И while тоже плохой?
опечатался, извиняюсь (мало спал) =)
имел ввиду with
----------------------------------------
window.open(window.location);
спасибо Вам за очень полезный и интересный сайт
Да - разница в скорости разных методов впечатляет
Это не всегда удается сделать, так как может придется менять не только innerHTML. Может быстрее будет удаление из документа узла средством removeChild() затем создание нового или изменение старого объекта, и в конце appendChild() ?
А теперь внимание!!!
Обнаружил падение скорости у себя в проекте. в итоге обнаружил
что Array.join - с большими строками (под 2-10кб) работает отвратительно под всеми браузерами.
а стандартная конктатенация через '+' - работает.... на 4 порядка быстрее!!! под IE8, и 3 порядка под FF3.6
Можете протестировать.
console.log(new Date().getTime());
q='';
for (var i=0; i < 2500; i++) {
q += 'dsfkbjdkvbnfdkwlfbgnmdekwlq;edfgnmdekwlq;dfgnemwlq;sdfbjnvmdls;afkbnmvd,lsfkbnjfdmsla';
}
console.log(new Date().getTime());
console.log(new Date().getTime());
q='';
for (var i=0; i < 2500; i++) {
q = [q, 'dsfkbjdkvbnfdkwlfbgnmdekwlq;edfgnmdekwlq;dfgnemwlq;sdfbjnvmdls;afkbnmvd,lsfkbnjfdmsla'].join('');
}
console.log(new Date().getTime());
Вы просто очень неэффективно записали второй цикл, нужно так:
q=[];
for (var i=0; i < 2500; i++) {
q.push('dsfkbjdkvbnfdkwlfbgnmdekwlq;edfgnmdekwlq;dfgnemwlq;sdfbjnvmdls;afkbnmvd,lsfkbnjfdmsla');
}
q.join('');
В этом варианте на моей машине при 25000 итерациях второй вариант проигрывает первому 2-3 миллисекунды в FF и Opera. В IE второй вариант вдвое эффективнее.
Главное чтобы подобные оптимизации не оказались экономией на спичках, прежде всего нужно писать грамотный и понятный код, а оптимизировать в тех случаях, когда производительность действительно снижается настолько, что это заметно человеческому глазу.
Да возможно, но чем тогда объясняется, данный проигрыш второго варианта?
И, ИМХО, конструкция с push не самая эффективная, быстрее должно быть так.
q[q.length] = 'fdfdfd';
Хотя бы тем, что вы в качестве индекса используете обращение к изменяемому свойству, это из разряда оптимизации описанной в «Более сложном примере», судя по всему.
Да, очень хорошая и познавательная статья, есть чему подучиться.
интересно что в ходе тестов сугубо на моей машине было выяснено что ишак в 10 раз медленнее чем хром.
Мда. Кто-то тут говорил о неприменимости MVC в яваскрипте, хотя эта статья убеждает в обратном.
С вашего позволения задам парочку вопросов.
[code]var s = '' + buffer.join('') + ''[/code]
Метод довольно быстрый, спору нет, что подтверждает вот этот Benchmark.
В процессе работы над проектом возник вопрос, а как правильно создавать таблицу с произвольным количеством столбцов? В моем случае приходится применять цикл. Как грамотнее в этом случае оптимизировать код?
У меня получается пока три шага:
На первом я формирую заголовки столбцов по принципу метода join " ... "
[code]var titleTable = "" + row_buffer.join('') + '\n';[/code]
А вот на втором надо сформировать основное тело таблицы в зависимости от кол-ва столбцов. И вот тут возникает вопрос. Каков самый оптимизированный метод из существующих?
"Рассмотрим заодно еще небольшую оптимизацию. Функция, которая назначается onclick внутри цикла - статическая. Вынесем ее вовне цикла:"
Кто-нибудь может объяснить, почему вынос функции так сильно влияет на скорость выполнения? И что происходит внутри, когда мы выносим функцию таким образом?
Некоторые оптимизации при проверке на Google Chrome приводят к совершенно обратным результатам. Для ИЕ и ФФ -- да, все работает. Так что аккуратно использовать надо.
Подскажите, будет ли разница в следующих скриптах?
и
Будет ли здесь выигрыш на отсутствии парсинга второй строки на каждой итерации цикла?
нет. на то как вы запишите код (с переносом или без) движку по большому счёту плевать
Нет, конечно. Парсинг производится один раз: по коду строится дерево разбора, а из него уже другие внутренние структуры движка.
Я так и не понял почему метод make Table 2 отработал в 8 раз медленней чем make Table ??
Все с вопросом разобрался, скорей всего алгоритм сложения строк изменился в современных браузерах и теперь при конкатенации не создается новая строка. в отличии от старого осла, так что теперь теперь конткатенация строк быстрей чем вариант с джоином