Исследуем скорость выполнения JS и алгоритм отображения страниц

[TheShock]

Странный результат для Хрома. Профилировали?
Интересна причина вплоть до строчки, почему так.
Может баг какой и оно в бесконечный цикл уходит?
Ато как-то даже не верится в такой тормоз.

[crea7or]

Делаем большой userjs скрипт для dirty.ru (200кб кода), есть с хромом странности со вставкой в уже большой DOM. Пока причин не поняли.

[TheShock]

на самом при разработке на Canvas заметил, что в страницах с серьёзной версткой значительно падает скорость отрисовки. Один position:relative и вместо 60 fps имеем 20 fps

[s0rr0w]

Тормозит все float: left и offsetLeft
Для плавающих элементов, скорее всего, пересчет координат запускается вновь и вновь на каждой итерации цикла.

[dos]

Раз вы используете последнюю версию Firefox, то попробуйте протестируйте последнюю версию Chrome 9.0.587

[widowmaker]

И Opera 11, а то FF — и бета ветки, а остальные из финальной.

[AYShestakov]

и Оперу 11 beta тогда уж.

[s0rr0w]

500: 560
750: 1140
1000: 1940

Результаты чуть лучше.

[dazran]

даже наверное 9.0.591 тогда

[s0rr0w]

На 500-х итерациях около 11400. Еще хуже, чем в 7й версии.

[Gruxon]

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

[s0rr0w]

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

[Mew]

[фанат оперы негодует!]Вообще, непонятно, почему опера от фф берется последний тестовый билд, а у оперы нет. Если причина, что типа опера альфа, а фф — бета, то это все ппц какие условности, кому как нравится — тот так и называет, альфа, бета. Помимо прочего, вчера появилась бета 11ой оперы.[/фанат оперы негодует!]

[AYShestakov]

не факт что 3.6.12 фокс проиграет опере — надо проверить.

[s0rr0w]

Факт, факт. Фокс 3.6 медленнее четверки процентов на 20 или около того.

[skobkin]

11 стала еще быстрее. Но до беты там в JS-движке была проблема в реализации bind, к примеру. GMail у многих не открывался.
А вот бета, думается, пройдет тест еще быстрее.

[ymik]

Если не сложно, выложите бенчмарк на каком-нибудь более вменяемом файлхостинге, чем рапидшара. На disk.yandex.ru к примеру

[Creatizmo]

Держите ссылку ;)

[xdevel]

попробовал везде где только смог :)
количество испытаний для каждого броузера — 7.

W7 x64

o11b — 399~411
ff4b7 — 670-681
ie8x64 — 1867~1929
ie8x32 — 2291~2388
chrome7.0.517.44 — 5514~5641
safari 5.0.3 (7533.19.4) — 2263~2495

linux mint 10 (стенд — слабее на порядок.)

o11b — 1272~1311
ff3.6.2 — 1434~1516
chrome7.0.517.44 — 7411~7655

[s0rr0w]

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

[mefcorvi]

Не знаю, как версия 5.5., но IE 6 складывает события reflow/repaint в очереди, и выполняет их по мере необходимости/возможности. К сожалению, у меня сейчас стоит лишь IE8, но в тесте без нагрузки он вдвое быстрее FF 3.6.12.

[bazzzman]

Я один такой тупой и не понимаю что значит выполняется «под нагрузкой» и «включаем тормоз»? 0_о
Значения оси абсцисс в обоих случаях одно и то же, время растёт. Получается разные алгоритмы тестирования. В чём разница?

Не могу скачать исходник теста чтобы поковыряться в нём.
Автор, разъясните это момент для тех кто в танке :)

[s0rr0w]

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

[bolk]

Если взяли бету FF, то возьмите и бету «Оперы».

[s0rr0w]

Бета Оперы будет иметь результаты или на уровне или чуть лучше стабильной версии. Архитектура, скорее всего не менялась, поэтому результаты будут вполне предсказуемы.

[SegaZero]

респект за термин «браузерная ориентация»:)
подняло настроение:)

[widowmaker]

Добавьте IE9b для сравнения

[widowmaker]

Проверил на Core i7 750:
FF 3.6.12 ~ 661
FF 4 b7 ~ 700
Chrome 9.0.587 ~ 8863
Opera 10.63 ~ 426
Opera 11 b1 ~ 403
IE 8 ~ 2423
IE 9 ~ 1018

[aavezel]

Ну, мне, кроме того, что в Chrome тормозит offsetLeft, этот тест ничего не дал… Пишите багу хромоделам… Но вначале попробуйте 9тую версию…

Если и делать тесты сравнивающие работу DOM, то делать другие версии тестов:
— создание таблицы NxN
— вставка в div N других div
— поиск div в N div по Id
— поиск div в N div по Name
— поиск div в N div по Query
— задание у div различных свойств (цвета, ширины, высоты и т.д.)

У всех этих тестов измерить время выполнения и время рендринга…

[s0rr0w]

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

[aavezel]

Архитектура архитектурой, а вот такие offsetLeft могут выскочить.

[s0rr0w]

1. Создание таблицы будет хорошо конвейеризировано.
2. Вставка не требует обратной связи после отрисовки.
3. Это вообще детская операция, давно оптимизирована.
4. Тут опять же, ничего не отрисовывается
5. Аналогично пункту 4
6. Нет обратной связи

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

[sky_lord]

Пробежался по статье и не вполне понял, чего автор так переживает? В документации Оперы для разработчиков черным и по белому и с примерами рассказывается о том, когда и при каких условиях делаются reflow/redraw. Прямым текстом сказано, что несколько последовательных происходящих за короткой время изменений в DOM действительно ставятся в очередь, а делаются потом «одним махом». Более того, в интернете есть куча обсуждений разработчиков, как наиболее простым способом это все обойти (а то иначе нет плавности, ну и в целом — есть же задачи, когда нужно чтобы результаты изменения DOM именно последовательно на странице отображались)… В основном рекомендуют offset<чего-нибудь> дергать или класс менять — короче, см. документацию Оперы по действиям, которые вызывают принудительный reflow. Если вы будете это делать, после каждого изменения DOM, то Опера начнет не только тормозить конкретно, но и скорее всего — станет еще медленнее остальных за счет накладных расходов.

Причины всего этого тоже очевидны: Фокс и Хром — это прежде всего десктопные браузеры в широком смысле, а Опера, как я уже тысячу раз говорил, на десктопе только себя отлаживает посредством тысяч коммитящих баги хомячков, а реальные деньги зарабатывает в embedded, поэтому у нее для этих целей все и оптимизировано…

[s0rr0w]

Я не переживаю.

[sky_lord]

Ну и славно! :-)
На случай, если не читали, гляньте, например: dev.opera.com/articles/view/efficient-javascript/?page=3
Это к тому, что особой интриги нет:

«Browsers may choose to wait until the end of a script thread before reflowing to show the changes. Opera will wait until enough changes have been made, enough time has elapsed, or the end of the thread is reached. This means that if the changes happen quickly enough in the same thread, they may only produce one reflow. However, this cannot be relied on, especially considering the various different speeds of devices that Opera runs on.»

[s0rr0w]

Спасибо, почитаю на досуге. Вообще молодцы ребята из Оперы. Уважаю.

[sky_lord]

Кстати, запустил ваш скрипт у себя — у меня Опера на 500 элементов выдает вообще 14500-1500 — связываю это с тем, что она, бедняжка, работает не покладая рук — открыто пять окон и несколько сотен вкладок. Надо будет на чистенькой проверить… :-)

Что касается самого скрипта — ИМХО, у вас там слишком много лишнего. Все, что внутри «if ( forceFeedback )» только вносит искажения непосредственно в тестирование скорости работы с DOM. Достаточно вызвать reflow чем-то типа «var aaa = cloneNode.offsetLeft;» — результаты будут аналогичными (чуть быстрее за счет отсутствия лишних телодвижений, но нам ведь и не их замерять надо).
Интереснее было бы заставить FF и Хром все-таки делать делать еще и redraw, чтобы они отрисовывали все по ходу процесса. Попробовал на скорую руку несколько типичных способов (см., например, ajaxian.com/archives/forcing-a-ui-redraw-from-javascript) — не получилось. Надо еще ковырять. Оперовцы в этом плане действительно молодцы — они хотя бы пишут, какие конкретно действия что вызывают…
А в Хроме явный баг, если он не делая redraw так откровенно всем сливает…

[s0rr0w]

Форcировать redraw можно чрез setInterval. Надо будет попробовать сделать такой тест.

[homm]

Если вы будете это делать, после каждого изменения DOM, то Опера начнет не только тормозить конкретно, но и скорее всего — станет еще медленнее остальных за счет накладных расходов.

Или я чего-то не понял, или именно дергание reflow и означает тест «под нагрузкой» (откройте файл из архива).

[sky_lord]

Да? ОК, проверю… Я же говорю — пробежался по статье, но исходники не глядел… Спасибо за информацию!

[Krypt]

Под Mac OS X 10.6.4 (Mac mini 1.83 GHz Core 2 Duo)
Opera 11.00 alpha (Сборка: 1029): 1746 ±30
Safari Версия 5.0.2 (6533.18.5): 8800 ±200

[s0rr0w]

Сафари имеет один движок с Хромом, результаты предсказуемы. Скорее всего слабое место WebKit'а в том, что для получения позиции элемента требуется вычислить позиции всех предыдущих элементов. А с ростом количества итераций объем обрабатываемых элементов растет экспоненциально, что, в принципе, заметно по числам.

[SKYnv]

сафари и хром имеет разные движки яваскрипта, хром это v8, сафари сквирельфиш. Движок рендеринга у них один — WebKit.

[s0rr0w]

За размеры элементов и их отображение на странице ответственен именно WebKit.

[SKYnv]

ай, звиняйте немного не так прочел ) все верно.

[mefcorvi]

SpeedTracer хрома подтверждает это предположение. В тормозном варианте, каждый вызов offsetLeft вызывает reflow, причем каждый следующий длится дольше предыдущего. На последних шагах у меня reflow длится уже по 45 милисекунд. Похоже, что в механизме rearrange элементов в хроме нет оптимизации для float-элементов.

[s0rr0w]

Или была допущена мысль, что сотня float-элементов подряд не является нормой для вебстраниц и усердной оптимизации не требует :)

[mefcorvi]

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

[s0rr0w]

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

[mefcorvi]

Кстати, в FF тоже вычисляются позиции всех элементов, ну или делаются ещё какие-то телодвижения. Дело в том, что если замерять результаты reflow по каждому шагу, то видно, что для поздних шагов этот процесс длится дольше, но если в хроме рост длительности идёт от 0 до 30 мс, причем рост экспоненциальный, то в FF от 0 до 3мс и выглядит линейным, так что может быть действительно это бага в исходниках хрома.

[freeart]

Странно, но быстрее всего из хромов отработал 4-й ~5000, все последующие версии все медленнее и медленнее…

[ArtyV]

Когда вы создаёте Node вы уже обращаетесь к DOM API и всё уже зависит от него, никакие «очереди» тут никак ни на что не повлияют.

[s0rr0w]

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

[ArtyV]

Точно так же как и не факт, что не на прямую. Это похоже на гадание, а не на тестирование

[mefcorvi]

Что вы имеете в виду, говоря что всё зависит от DOM API? На то он и API, что это лишь описанный и стандартизированный интерфейс к движку браузера, в котором упомянутые очереди уже и реализуются.

[kashey]

Redraw,Reflow,Fragments
эх, как много интересных чтук придумали люди чтобы заставить браузеры отрабатывать пачкой.

[Frenzy]

Ну вы нашли конечно куда код бенчмарка залить. И это во времена гитхабов и битбакетов.

[s0rr0w]

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

[homm]

pastie, нет?

[s0rr0w]

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

[mefcorvi]

Переложил исходник на pasteBin если кому интересно.
pastebin.com/DkVmWySU

[adminimus]

есть у меня один доморощенный бенчмарк на DOM. Точнее, это реальная страница из одной нашей внутренней системы, на ней отображаются результаты поиска в виде таблицы, приходящей в виде XML с сервера (XML -> XML DOM -> HTML DOM -> render ). Страница превратилась в бенчмарк после того, как один из пользователей попросил сделать ему отображение по 1000 строк на каждой странице. В результате стоявшая у него тогда опера 10.10 уходила в нирвану на минуту :) Теперь я этой страницей тестирую свежие браузеры. Вот текущие результаты:

ff 3.6.10          ~ 5600 ms
opera 10.63    ~ 550 ms
webkit 532.4   ~ 520 ms

вне конкурса
ff 4b7              ~550 ms (причем в ней видимо парсинг xml быстрее вебкита, на глаз полное время от запроса до рендера заметно меньше)

[adminimus]

опечатка

opera 10.63    ~ 3500 ms

[djko]

возможно будут интересны следующие ссылки:
www.browserscope.org/reflow/test — рефлоу тест
www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/ — тут есть много тулов для рефлоу тестов и даже букмарклет для теста в разных браузерах.

[skobkin]

Скачал тест с народа. Интересные результаты:
Opera 11 beta: 408 +- 10
Chrome 7.0.517.44: 4102 +- 300 (кулер на процессоре во время теста резко повышает обороты)
IE 9 beta: 1045 +- 15
FF 4 beta 7: 772 +- 100

Тестировал на Core i5 750… Очень удивил результат хрома.

[tenshi]

ещё один синтетический тэст…

[s0rr0w]

Открою вам маленький секрет — не синтетических тестов в мире не бывает

[tenshi]

бывает

[s0rr0w]

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

[tenshi]

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

[s0rr0w]

Ограничение юзкейсов только определенным набором делают тесты синтетическими.

[tenshi]

нет, синтетические — это нереалистичные. например, реализация заведомо неэффективного алгоритма.

[s0rr0w]

Тогда чем приведенный тест синтетический? Неэффективный алгоритм? Извините, но это проблемы недостаточной оптимизации браузера. Нереалистичный дизайн, что получается в итоге? Ой не факт, вполне себе нормальное дизайнерское требование.

[tenshi]

это проблемы недостаточной квалификации программиста

[s0rr0w]

Как всегда туманные далекие фразы… Никакой конкретики.

[eatart]

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

[s0rr0w]

Ежики плакали, матерились, но продолжали жрать кактус?

[eatart]

типа того, работа такая

[s0rr0w]

Сочувствую.

[cherepanov]

Давно заметил. В хроме больше десяти открытых вкладок и дает 100% CPU на любой машине, видно затык на отрисовке.

[Sannis]

Имхо, графики нужно строить при i=50...200, всё-таки это наиболее используемое на данный момент количество однотипных элементов на странице. Отсюда и разочарование.

[s0rr0w]

0 отличать от 0 как будете? :)

[Sannis]

Это будет говорить о том, что в нормальных условиях все движки примерно одинаковые :-) А на синтетических тестах можно получить любой необходимый результат.

[s0rr0w]

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

Не бывает одинаковых движков. У всех есть недостатки, и их надо знать в лицо. 500 элементов не так много для веб-приложения.