Javascript-форум (https://javascript.ru/forum/)
-   Общие вопросы Javascript (https://javascript.ru/forum/misc/)
-   -   Какой движок использует опера? (https://javascript.ru/forum/misc/49378-kakojj-dvizhok-ispolzuet-opera.html)

newobject 10.08.2014 20:36

Какой движок использует опера?
 
вот тут
http://habrahabr.ru/post/175403/
написано:
Цитата:

«Все наши новые продукты будут использовать движок WebKit для рендеринга и V8 для обработки JavaScript. Они будут основаны на опенсорсном браузере Chromium и его компонентах
статья датирована 4 апреля 2013 в 10:25
Я щас обновил оперу до 12.17 и вижу
Browser identification
Opera/9.80 (Windows NT 5.1) Presto/2.12.388 Version/12.17
непонято, перешли они или нет? По скорости движка особ не заметно: на одной и той же странице я проверил оперу и хром -- разница в обработке скриптов огромная, явно разые движки. Или че там за магия происходит?

devote 10.08.2014 20:48

Цитата:

Сообщение от newobject
Я щас обновил оперу до 12.17 и вижу

это старая версия, качать нужно с сайта оперы там сейчас лежит 22-я или 23-я точно не скажу, но 12-я уже старая.

newobject 10.08.2014 21:07

devote,
Спасибо, да скачал -- оказалось таким же тормозным говном как и хром. Жаль.

ixth 10.08.2014 21:25

Лол. Чуви, то, что твой код тормозит под v8 еще не значит, что Хром — тормозное говно.

Aetae 10.08.2014 21:32

Хром - тормозное говно! Дискач?

newobject 10.08.2014 21:32

ixth,
Я тут немного подумал, и понял причину тормозов того кода, более или менее. Там вот что происходит. Если запущен цикл, браузер не может обработать пользовательский ввод. то есть, я жму на клаву, и события эти становяться в очередь. Изнутри цикла ты не сможешь захватить действия пользователя, события. Тут тупиковый вариант, архитектурная лажа. Следовательно, цикл по любому выполняется, что в хроме, что в фф, где угодно. А это значит, что V8 отсасывает не на чем то там космическо-волшебном, а на банальной обработке массива. Попросту говоря, он не умеет массивы. Как вариант -- регекспы. А нахрен, спрашивается, такой двиг нужен, если он сосет на ключевых вещах?

ixth 10.08.2014 23:00

Ох, щи… Правильно написанный код под v8 иногда даже рвет (неоптимизированный) нативный C++, ЕМНИМС. Покажи мне тесткейсы, на которых v8 по-твоему сосет.

newobject 10.08.2014 23:34

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

ixth 10.08.2014 23:55

Знаешь что меня забавляет? Наблюдать как люди вокруг вместо того чтобы скромно следовать заветам Сократа и считать, что они ничего не знают, сразу находят причину своих проблем снаружи. Это, кажется, называется ресентимент. Я написал код, который тормозит и мне лень пораскинуть мозгами? Это все браузер виноват! Я не понимаю декларативного подхода? Нет, это просто тупой шаблонизатор! Грустно, в общем. В итоге хорошие вещи обычно оказываются оплеваны людьми, которые даже не попытались научиться их готовить.

Твой код тормозил по распространенной причине: ты пытался запихнуть в innerHTML СЛИШКОМ много. Браузер просто давился, пересчитывая DOM и все, что с этим связано. Бла-бла-бла, даже я не вдаюсь в причины. Решение — использовать ф-цию replaceHTML, которая делает странное. Найдешь ее в обновленном коде.

http://jsfiddle.net/ainop/g41x6tto/5/

newobject 11.08.2014 01:13

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

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)

<html>
	 
	<head>
	    <title>Untitled</title>
	</head>
	 
	<body>
<div id="id"><div>

<script>

test=function(fu, i){
console.time(fu.name)
while(i--){fu()}
console.timeEnd(fu.name)
}

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;
};

str="fooooooooooooooooooovvvvvmvmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmddssmxmxmxmxm"

function replace(){replaceHtml("id", str)}
function inner(){document.getElementById("id").innerHTML=str}
i=10000
test(replace, i)
test(inner, i)

</script>
</body>
	</html>


По сабжу: новый код ничуть визуально не отличается от предыдущих версий: на V8 тормозит ввод. Что не удивительно: на других двигах ко времени ввода следующего символа цикл успевает закончится, а на тормозном V8 -- нет. Никакой магии:)

ЗЫ и причем тут декларативный подход ЯННП?

ixth 11.08.2014 09:43

Цитата:

Сообщение от newobject (Сообщение 325267)
ixth,
Я уж не знаю, как этот чувачок там тестировал ЭТО, но мои тесты кагбэ не подтверждают, мягко говоря, его позицию. Видимо не случайно ссылка с реальными тестами у него ведет в никуда, а выложены только результаты.

Держи тесты, фома неверующий. На моей версии хрома replaceHMTL обгоняет innerHTML совсем немного, но судя по графикам, прирост может быть в разы больше: http://jsperf.com/innerhtml-vs-replacehtml

Если бы все было иначе, я бы не спорил.

Цитата:

Сообщение от newobject (Сообщение 325267)
Вот мои результаты:

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 (Сообщение 325267)
По сабжу: новый код ничуть визуально не отличается от предыдущих версий: на V8 тормозит ввод. Что не удивительно: на других двигах ко времени ввода следующего символа цикл успевает закончится, а на тормозном V8 -- нет. Никакой магии:)

Откуда у тебя такое тайное знание? :-E Я свое (про innerHTML) почерпнул из профайлера, могу показать скрины.
И да, расскажи про машину, на которой все это выполняется. Нетбук какой-то? Какая версия Хрома? Я просто давно не видел, чтобы что-то js- ное тормозило.

Цитата:

Сообщение от newobject (Сообщение 325267)
ЗЫ и причем тут декларативный подход ЯННП?

«XSLT тормозное говно! Ничего не понятно! Зачем он нужен?», — обычно говорят люди, не разобравшись в подходе.

newobject 11.08.2014 10:46

Цитата:

Сообщение от ixth
Откуда у тебя такое тайное знание?

Я просто прикинул логически. Иначе быть не может. Я уже писал: когда начинается цикл он блокирует все, в том числе и пользовательский ввод. Пользователь печатает, но буковы не приходят сразу в инпут, а становятся в очередь, и отобразятся только после выполнения цикла, когда управление вернется к браузеру. Тут самым очевидным решением представляется -- прервать цикл в момент ввода, но пока выполняется цикл он не может получить событие ввода, он занимает единственный поток, и пока он его занимает, события не получаются браузером. Это неразрешимая проблема. Если пускать каждую итерацию отдельным таймаутом, на каждой итерации управление будет таки возвращатся к браузеру, но мы получим медленное выполнение цикла тогда. Отсюда и выводы
Цитата:

Сообщение от ixth
Как видишь, на больших объемах replaceHTML у меня немного быстрее. Судя по jsperf, в других браузерах innerHTML работает еще хуже.

Даже если и так, это копейки. Сравни время обхода в цикле большого массива с проверками и время вставки куска в документ. Это фигня.
Цитата:

Сообщение от ixth
И да, расскажи про машину, на которой все это выполняется.

Я щас на работе, не могу точно сказать. Ноутбук ушатанный, ему лет 8. Помню, что там 2 ядра, оперативы меньше гига, частота меньше 2-х. Процессор -- amd атлон, ЕМНИП. Вот на работе тоже слабая машина, ОЗУ - 1,48, CPU - 2,26, INTEL, не тормозит вообще. Вот, как раз такие вещи удобно тестить на древних слабых машинах, а то бы я и не знал, что хром говно.:)

devote 11.08.2014 11:18

а причем тут вообще DOM? топикстартер срёт V8 а тесты проводит замеряя обработку DOM...

ixth 11.08.2014 11:39

Цитата:

Сообщение от newobject (Сообщение 325285)
Я просто прикинул логически. Иначе быть не может.

Пока ты не препарируешь браузер, наверняка знать не будешь.

Цитата:

Сообщение от newobject (Сообщение 325285)
Это неразрешимая проблема.

Черт, ты так просто опускаешь руки, оправдываясь тем, что "Хром говно"… Мне аж обидно.

Цитата:

Сообщение от newobject (Сообщение 325285)
Если пускать каждую итерацию отдельным таймаутом, на каждой итерации управление будет таки возвращатся к браузеру, но мы получим медленное выполнение цикла тогда. Отсюда и выводы

А ты попробуй. Вдруг получится быстрее.

Цитата:

Сообщение от newobject (Сообщение 325285)
Даже если и так, это копейки. Сравни время обхода в цикле большого массива с проверками и время вставки куска в документ. Это фигня.

Лол. Посмотри на график. Видишь огромные оранжевые палки? Это количество операций в секунду для replaceHTML. Во всех версиях он быстрее, в некоторых — в 1,5-2 раза.


Профайлинг кода с innerHTML:


И с replaceHTML:


Как видишь, вариант с replaceHTML выполняется за 10 миллисекунд. С innerHTML — за 5000 (5 секунд то есть). Никакого объяснения, кроме того, что Хром не любит объемный innerHTML у меня нет. Поиск с регулярками в профиле занимает какое-то смешное время, так что я его тут не привожу.

newobject 11.08.2014 13:13

ixth,
Да, похоже ты прав, я думал цикл долго выполняется, а оказывается, отрисовка выполняется в десятки раз дольше, если верить отладчикам. Если это так, то тут не надо, наверное онанировать на скорость innerHTML vs replace, тем более, это не кроссбраузерное решение. Тут надо пытаться сделать асинхронную отрисовку, возможно кусками.
Спасибо за помощь.

ixth 11.08.2014 13:43

Проблема не совсем в скорости отрисовки. Если посмотреть на маленькие сиреневые прямоугольнички, то видно, что они отрабатывают довольно быстро, а весь тупняк идет до них. Проблема именно в присвоении innerHTML. Еще раз: replaceHTML выполняется в 100 (sic!) раз быстрее, за 10 миллисекунд против пяти секунд innerHTML.

Но, в принципе, да, проблему лучше решать сменой подхода.


Часовой пояс GMT +3, время: 14:09.