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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Под 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

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

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

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

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

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

есть у меня один доморощенный бенчмарк на 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 быстрее вебкита, на глаз полное время от запроса до рендера заметно меньше)

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

Скачал тест с народа. Интересные результаты:
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… Очень удивил результат хрома.

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

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

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

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