11.08.2014, 09:43
|
 |
Профессор
|
|
Регистрация: 19.01.2010
Сообщений: 354
|
|
Сообщение от newobject
|
ixth,
Я уж не знаю, как этот чувачок там тестировал ЭТО, но мои тесты кагбэ не подтверждают, мягко говоря, его позицию. Видимо не случайно ссылка с реальными тестами у него ведет в никуда, а выложены только результаты.
|
Держи тесты, фома неверующий. На моей версии хрома replaceHMTL обгоняет innerHTML совсем немного, но судя по графикам, прирост может быть в разы больше: http://jsperf.com/innerhtml-vs-replacehtml
Если бы все было иначе, я бы не спорил.
|
Сообщение от newobject
|
Вот мои результаты:
ff:
replace: 125ms
inner: 47ms
chrome:
replace: 191.000ms
inner: 91.000ms
opera:
replace: 257.000ms
inner: 116.000ms
старая опера:
replace: 445ms (445010µsec)
inner: 250ms (250109µsec)
|
replaceHTML ведет себя лучше на ДЕЙСТВИТЕЛЬНО БОЛЬШИХ объемах текста (на самом деле, количество элементов важнее). У тебя же такая проблема?
<html>
<head>
<title>Untitled</title>
</head>
<body>
<div id="id"><div>
<script>
var str = Array(1000).join("fooooooooooooooooooovvvvvmvmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmddssmxmxmxmxm");
var strWithElems = Array(1000).join("fooooo<br/>oooooooo<br/>oooooovvvvvmvmmm<br/>mmmmmmmmmmmm<br/>mmmmmmmmmmmmm<br/>mmmmmmmmmmmmm<br/>mddssmxmxmxmxm");
var elem = document.getElementById("id");
test('innerHTML with simple text', function () {
elem.innerHTML = str;
}, 1000);
test('replaceHTML with simple text', function () {
elem = replaceHtml(elem, str);
}, 1000);
test('innerHTML with complex text', function () {
elem.innerHTML = strWithElems;
}, 1000);
test('replaceHTML with complex text', function () {
elem = replaceHtml(elem, strWithElems);
}, 1000);
function test(title, fn, i) {
console.time(title);
while (i--) { fn(); }
console.timeEnd(title);
}
function replaceHtml(el, html) {
var oldEl = typeof el === "string" ? document.getElementById(el) : el;
/*@cc_on // Pure innerHTML is slightly faster in IE
oldEl.innerHTML = html;
return oldEl;
@*/
var newEl = oldEl.cloneNode(false);
newEl.innerHTML = html;
oldEl.parentNode.replaceChild(newEl, oldEl);
/* Since we just removed the old element from the DOM, return a reference
to the new element, which can be used to restore variable references. */
return newEl;
};
</script>
</body>
</html>
|
Код:
|
innerHTML with simple text: 579.010ms
replaceHTML with simple text: 535.914ms
innerHTML with complex text: 9071.508ms
replaceHTML with complex text: 8032.101ms |
Как видишь, на больших объемах replaceHTML у меня немного быстрее. Судя по jsperf, в других браузерах innerHTML работает еще хуже.
|
Сообщение от newobject
|
По сабжу: новый код ничуть визуально не отличается от предыдущих версий: на V8 тормозит ввод. Что не удивительно: на других двигах ко времени ввода следующего символа цикл успевает закончится, а на тормозном V8 -- нет. Никакой магии
|
Откуда у тебя такое тайное знание?  Я свое (про innerHTML) почерпнул из профайлера, могу показать скрины.
И да, расскажи про машину, на которой все это выполняется. Нетбук какой-то? Какая версия Хрома? Я просто давно не видел, чтобы что-то js- ное тормозило.
|
Сообщение от newobject
|
|
ЗЫ и причем тут декларативный подход ЯННП?
|
«XSLT тормозное говно! Ничего не понятно! Зачем он нужен?», — обычно говорят люди, не разобравшись в подходе.
|
|
11.08.2014, 10:46
|
|
Профессор
|
|
Регистрация: 10.07.2014
Сообщений: 145
|
|
|
Сообщение от ixth
|
|
Откуда у тебя такое тайное знание?
|
Я просто прикинул логически. Иначе быть не может. Я уже писал: когда начинается цикл он блокирует все, в том числе и пользовательский ввод. Пользователь печатает, но буковы не приходят сразу в инпут, а становятся в очередь, и отобразятся только после выполнения цикла, когда управление вернется к браузеру. Тут самым очевидным решением представляется -- прервать цикл в момент ввода, но пока выполняется цикл он не может получить событие ввода, он занимает единственный поток, и пока он его занимает, события не получаются браузером. Это неразрешимая проблема. Если пускать каждую итерацию отдельным таймаутом, на каждой итерации управление будет таки возвращатся к браузеру, но мы получим медленное выполнение цикла тогда. Отсюда и выводы
|
Сообщение от ixth
|
|
Как видишь, на больших объемах replaceHTML у меня немного быстрее. Судя по jsperf, в других браузерах innerHTML работает еще хуже.
|
Даже если и так, это копейки. Сравни время обхода в цикле большого массива с проверками и время вставки куска в документ. Это фигня.
|
Сообщение от ixth
|
|
И да, расскажи про машину, на которой все это выполняется.
|
Я щас на работе, не могу точно сказать. Ноутбук ушатанный, ему лет 8. Помню, что там 2 ядра, оперативы меньше гига, частота меньше 2-х. Процессор -- amd атлон, ЕМНИП. Вот на работе тоже слабая машина, ОЗУ - 1,48, CPU - 2,26, INTEL, не тормозит вообще. Вот, как раз такие вещи удобно тестить на древних слабых машинах, а то бы я и не знал, что хром говно.
|
|
11.08.2014, 11:18
|
|
что-то знаю
|
|
Регистрация: 24.05.2009
Сообщений: 5,176
|
|
|
а причем тут вообще DOM? топикстартер срёт V8 а тесты проводит замеряя обработку DOM...
|
|
11.08.2014, 11:39
|
|
Профессор
|
|
Регистрация: 19.01.2010
Сообщений: 354
|
|
|
Сообщение от newobject
|
|
Я просто прикинул логически. Иначе быть не может.
|
Пока ты не препарируешь браузер, наверняка знать не будешь.
|
Сообщение от newobject
|
|
Это неразрешимая проблема.
|
Черт, ты так просто опускаешь руки, оправдываясь тем, что "Хром говно"… Мне аж обидно.
|
Сообщение от newobject
|
|
Если пускать каждую итерацию отдельным таймаутом, на каждой итерации управление будет таки возвращатся к браузеру, но мы получим медленное выполнение цикла тогда. Отсюда и выводы
|
А ты попробуй. Вдруг получится быстрее.
|
Сообщение от newobject
|
|
Даже если и так, это копейки. Сравни время обхода в цикле большого массива с проверками и время вставки куска в документ. Это фигня.
|
Лол. Посмотри на график. Видишь огромные оранжевые палки? Это количество операций в секунду для replaceHTML. Во всех версиях он быстрее, в некоторых — в 1,5-2 раза.
Профайлинг кода с innerHTML:
И с replaceHTML:
Как видишь, вариант с replaceHTML выполняется за 10 миллисекунд. С innerHTML — за 5000 (5 секунд то есть). Никакого объяснения, кроме того, что Хром не любит объемный innerHTML у меня нет. Поиск с регулярками в профиле занимает какое-то смешное время, так что я его тут не привожу.
|
|
11.08.2014, 13:13
|
|
Профессор
|
|
Регистрация: 10.07.2014
Сообщений: 145
|
|
|
ixth,
Да, похоже ты прав, я думал цикл долго выполняется, а оказывается, отрисовка выполняется в десятки раз дольше, если верить отладчикам. Если это так, то тут не надо, наверное онанировать на скорость innerHTML vs replace, тем более, это не кроссбраузерное решение. Тут надо пытаться сделать асинхронную отрисовку, возможно кусками.
Спасибо за помощь.
|
|
11.08.2014, 13:43
|
|
Профессор
|
|
Регистрация: 19.01.2010
Сообщений: 354
|
|
|
Проблема не совсем в скорости отрисовки. Если посмотреть на маленькие сиреневые прямоугольнички, то видно, что они отрабатывают довольно быстро, а весь тупняк идет до них. Проблема именно в присвоении innerHTML. Еще раз: replaceHTML выполняется в 100 (sic!) раз быстрее, за 10 миллисекунд против пяти секунд innerHTML.
Но, в принципе, да, проблему лучше решать сменой подхода.
|
|
|
|
