Comments 46
Не надо мне говорить, про удобство и разделение дизайна и кода.
А что, промолчать не трудно.
А что, промолчать не трудно.
А результаты тестов у вас в чём, в попугаях?
Абсолютным победителем, во всех тестах признан Chrome, кто бы сомневался.
Это в каком месте? По вашей же табличке FF делает Chrome показывая лучшее максимальное время. То что минимальное время у последнего 0 говорит лишь о том что он хорошо кэширует.
IE8, на удивление, сравнимо с Оперой. Лично я в шоке.
Это в каком месте? И к стати какая версия Оперы?
У меня результаты Оперы были сравнимы со всеми кроме IE.
лучшее максимальное время
Главное это среднее и минимальное. Макс может прыгать из за того что ко мне кто-то по сети долбанулся, или звезда Юпитера перегрелась… :)
То что минимальное время у последнего 0
Что там кешировать? :) 0 это значит меньше миллисекунды.
И к стати какая версия Оперы?
Opera 10.63
> Макс может прыгать из за того что ко мне кто-то по сети долбанулся, или звезда Юпитера перегрелась… :)
То есть максимальное значение надо тупо выбросить? :)
Неправильно. Представьте, что у вас получился вот такой набор данных:
20, 50, 99, 100, 110
Тут надо выбрасывать максимум или нет?
А в ситуации с 10, 20, 30, 40, 200?
Здесь интуиция подсказывает, что 200 очень сильно выпадает из этого ряда. Если считать с ним, то среднее будет равно 60, а если без него, то всего 25. Разница огромна не так ли? Почти в 3 раза. Если у нас будут такие отклонения в результатах, то на бумаге какой-нибудь допотопный ИЕ «уложит на лопатки» свежий Хром.
Чтобы понять, надо его отбрасывать или нет, надо отбросить мусор по «Правилу трех сигм» и потом обрабатывать данные. То есть во втором случае 200 четко выкидывается, и максимум у нас равен 40, а не 200! Понимаете?
Аналогично выбрасывается минимум.
Потом нам для каждой последовательности замеров нужно посчитать среднее и дисперсию. И средние значения для разных браузеров имеет смысл сравнивать только с учетом дисперсии — используем t-критерий Стьюдента.
Если не заморачиваться математикой, то надо оценить ошибку среднего и записать его в виде, например, 9±3 мс.
И если у вас получаются результаты: 9±3 мс и 10±2 мс, то это не значит, что первый способ быстрее на 10% — это значит, что они одинаковы по скорости.
Пока у нас нет строгой статистической обработки данных, все результаты будут с точностью ±лапоть. А значит делать выводы можно только с натяжкой.
То есть максимальное значение надо тупо выбросить? :)
Неправильно. Представьте, что у вас получился вот такой набор данных:
20, 50, 99, 100, 110
Тут надо выбрасывать максимум или нет?
А в ситуации с 10, 20, 30, 40, 200?
Здесь интуиция подсказывает, что 200 очень сильно выпадает из этого ряда. Если считать с ним, то среднее будет равно 60, а если без него, то всего 25. Разница огромна не так ли? Почти в 3 раза. Если у нас будут такие отклонения в результатах, то на бумаге какой-нибудь допотопный ИЕ «уложит на лопатки» свежий Хром.
Чтобы понять, надо его отбрасывать или нет, надо отбросить мусор по «Правилу трех сигм» и потом обрабатывать данные. То есть во втором случае 200 четко выкидывается, и максимум у нас равен 40, а не 200! Понимаете?
Аналогично выбрасывается минимум.
Потом нам для каждой последовательности замеров нужно посчитать среднее и дисперсию. И средние значения для разных браузеров имеет смысл сравнивать только с учетом дисперсии — используем t-критерий Стьюдента.
Если не заморачиваться математикой, то надо оценить ошибку среднего и записать его в виде, например, 9±3 мс.
И если у вас получаются результаты: 9±3 мс и 10±2 мс, то это не значит, что первый способ быстрее на 10% — это значит, что они одинаковы по скорости.
Пока у нас нет строгой статистической обработки данных, все результаты будут с точностью ±лапоть. А значит делать выводы можно только с натяжкой.
Если переименуете ваш файл в dropbox-е в расширение html будет имхо удобнее
И оно станет недоступным :( dl.dropbox.com/u/2183289/templates_test.html
Оставьте совсем без расширения, должно сработать.
тогда используйте jsfiddle.net =)
Как вставить <script type=«text/x-jquery-tmpl» id=«microsoft_template»>… </script> ???
прямо в поле html, думаю. оно же не обязательно в head быть должно?
Маленький хинт: если дописать show к адресу, то показывается только результат, без редактирования: jsfiddle.net/W4H8K/show
Firefox 4 beta 7:
Microsoft templates PureJSTemplate Кривые руки Выпрямленные
102ms 4ms 180ms 4ms
96ms 3ms 186ms 4ms
97ms 3ms 184ms 4ms
97ms 4ms 185ms 3ms
97ms 3ms 185ms 4ms
97ms 3ms 190ms 4ms
105ms 3ms 213ms 4ms
97ms 4ms 187ms 4ms
99ms 4ms 186ms 4ms
98ms 4ms 734ms 6ms
Chrome 8.0.552.200 beta:
67ms 6ms 139ms 6ms
62ms 6ms 138ms 6ms
67ms 6ms 118ms 5ms
82ms 6ms 120ms 5ms
94ms 5ms 226ms 6ms
65ms 6ms 119ms 5ms
68ms 6ms 121ms 6ms
90ms 5ms 354ms 6ms
70ms 5ms 137ms 5ms
66ms 5ms 122ms 6ms
Opera 11 alpha build 1060:
240ms 17ms 368ms 34ms
185ms 14ms 357ms 24ms
184ms 16ms 272ms 6ms
195ms 14ms 387ms 22ms
181ms 16ms 259ms 19ms
186ms 15ms 284ms 9ms
193ms 14ms 419ms 12ms
178ms 14ms 423ms 12ms
186ms 14ms 412ms 13ms
173ms 14ms 556ms 7ms
Internet Explorer 8:
509ms 116ms 878ms 18ms
435ms 115ms 869ms 18ms
440ms 113ms 870ms 14ms
441ms 113ms 879ms 15ms
447ms 118ms 897ms 15ms
446ms 114ms 886ms 15ms
449ms 114ms 887ms 14ms
444ms 115ms 893ms 14ms
447ms 120ms 879ms 15ms
453ms 119ms 882ms 16ms
Firefox 4 beta 7:
Microsoft templates PureJSTemplate Кривые руки Выпрямленные
102ms 4ms 180ms 4ms
96ms 3ms 186ms 4ms
97ms 3ms 184ms 4ms
97ms 4ms 185ms 3ms
97ms 3ms 185ms 4ms
97ms 3ms 190ms 4ms
105ms 3ms 213ms 4ms
97ms 4ms 187ms 4ms
99ms 4ms 186ms 4ms
98ms 4ms 734ms 6ms
Chrome 8.0.552.200 beta:
67ms 6ms 139ms 6ms
62ms 6ms 138ms 6ms
67ms 6ms 118ms 5ms
82ms 6ms 120ms 5ms
94ms 5ms 226ms 6ms
65ms 6ms 119ms 5ms
68ms 6ms 121ms 6ms
90ms 5ms 354ms 6ms
70ms 5ms 137ms 5ms
66ms 5ms 122ms 6ms
Opera 11 alpha build 1060:
240ms 17ms 368ms 34ms
185ms 14ms 357ms 24ms
184ms 16ms 272ms 6ms
195ms 14ms 387ms 22ms
181ms 16ms 259ms 19ms
186ms 15ms 284ms 9ms
193ms 14ms 419ms 12ms
178ms 14ms 423ms 12ms
186ms 14ms 412ms 13ms
173ms 14ms 556ms 7ms
Internet Explorer 8:
509ms 116ms 878ms 18ms
435ms 115ms 869ms 18ms
440ms 113ms 870ms 14ms
441ms 113ms 879ms 15ms
447ms 118ms 897ms 15ms
446ms 114ms 886ms 15ms
449ms 114ms 887ms 14ms
444ms 115ms 893ms 14ms
447ms 120ms 879ms 15ms
453ms 119ms 882ms 16ms
Да, кстати мелкософтный темплейтер вы тоже кривыми руками заюзали.
В pureJS цикл внутри темплейта, а у мелкософтного вы сначала получаете массив из 100500 dom-объектов, а только потом его добавляете.
Темплейт должен быть такой: {{each elements}}${value}{{/each}}
а вызов: $("#microsoft_template").tmpl({elements:elements}).appendTo($("#out"));
Сильно это данному движку не поможет, зато результат будет лучше «кривых рук» (но хуже других)
В pureJS цикл внутри темплейта, а у мелкософтного вы сначала получаете массив из 100500 dom-объектов, а только потом его добавляете.
Темплейт должен быть такой: {{each elements}}${value}{{/each}}
а вызов: $("#microsoft_template").tmpl({elements:elements}).appendTo($("#out"));
Сильно это данному движку не поможет, зато результат будет лучше «кривых рук» (но хуже других)
Не помогло. В Opere оно стало еще дольше. В других уменьшилось, но не намного… тут
Microsoft намеренно выпустила тормознутый продукт, для того чтобы запугать рынок AJAX приложений
Да, ладно…
Просто jQuery-tmpl — это сильно перенавороченный Javascript Micro-Templating от John Resig (http://ejohn.org/blog/javascript-micro-templating/) или tmpl. Никто его не пытался делать тормозом специально, просто МС, как всегда решил сделать круче, чем у конкурентов и перестарался.
Если использовать tmpl, то время равно времени pureJsTemplate во всех браузерах с точностью до 10 мс. Это означает, что tmpl и pureJsTemplate — это предел скорости для шаблонизаторов.
Кстати, у меня «Выпрямленные руки» отработали быстрее всех остальных методов во всех браузерах.
Добавил свой, дополненный вариант теста сюда
tmpl у меня работал в 10 раз медленнее главного героя. может, конечно, версия была старая, январь где-то.
да и не думаю, что сам джон не приложил руку и тупо отдал свой шаблонизатор на растерзание
да и не думаю, что сам джон не приложил руку и тупо отдал свой шаблонизатор на растерзание
Вы бы прежде чем обличать и выводить на чистую воду ms, провели сравнение возможностей, багов, и т.д. в реальной среде.
Это сферический тест в вакууме, который показывает что для обработки стапятиста элементов плагин в n раз медленнее конкурентов. Когда вам в реальном проекте надо было вставить 1000 элементов на странице шаблонизатором, или даже сто? Причем 210мс — это 1/5 секунды, что практически незаметно для конечного юзера. В жизни же все способы будут показывать результаты
Это сферический тест в вакууме, который показывает что для обработки стапятиста элементов плагин в n раз медленнее конкурентов. Когда вам в реальном проекте надо было вставить 1000 элементов на странице шаблонизатором, или даже сто? Причем 210мс — это 1/5 секунды, что практически незаметно для конечного юзера. В жизни же все способы будут показывать результаты
[съедено парсером] менее десяти мс.
В некоторых проектах, где основной заказчик большие тётки в очках, ajax запросы бывают в пару мегабайт, а количество строк за десяток тысяч…
И вы это все разом рисуете? В таком случае нужно порциями выводить, и незачем сразу все запрашивать с сервера.
Не приходилось сталкиваться ни с такими тетками, ни с такими требованиями =)
Такие редкие и узкоспециализированные задачи обычно требуют создания собственных инструментов, а не использования сторонних плагов.
Приложения бывают быстрыми, стабильными, удобными; но из трех качеств каждое может обладать только двумя.
Такие редкие и узкоспециализированные задачи обычно требуют создания собственных инструментов, а не использования сторонних плагов.
Приложения бывают быстрыми, стабильными, удобными; но из трех качеств каждое может обладать только двумя.
>Приложения бывают быстрыми, стабильными, удобными; но из трех качеств каждое может обладать только двумя.
у этого правила есть апдейт:
Приложения бывают быстрыми, стабильными, удобными, недорогими; но из 4 этих качеств, каждое может обладать максимум тремя
у этого правила есть апдейт:
Приложения бывают быстрыми, стабильными, удобными, недорогими; но из 4 этих качеств, каждое может обладать максимум тремя
Зачем? Если немного модифицированный PureJS почти всех устраивает?
это крайний случай, тут даже jQuery если выкинуть будет чуточку быстрее
Вот это +1. У кого есть задача выводить именно 100500 спанов — ок, MS не подойдет, но, если нужно вывести пять карточек клиента по 15 полей — MS катит без вопросов.
В общем всему свой инструмент, и чем больше инструментов, тем больше шанс, что что-то точненько подойдет под ваши задачи.
В общем всему свой инструмент, и чем больше инструментов, тем больше шанс, что что-то точненько подойдет под ваши задачи.
$("#out").html(spans.join(""));
заменяем на
var result = spans.join("");
6ms -> 1ms
Зачем в тест javascript'a, примешивать еще и рендеринг страницы?
заменяем на
var result = spans.join("");
6ms -> 1ms
Зачем в тест javascript'a, примешивать еще и рендеринг страницы?
экранировать данные кто будет? дядя?
Вообще-то если уж Вы взялись тестировать, то не обязательно ваять тесты на коленке. Примерно год назад Brian Landau написал неплохой тест, куда легко подключать новые движки. Исходники он выложил на github, так что не проблема скачать/подстучать под свои нужды.
Дальше, кроме скорости движки обычно отличаются некоторыми важными характеристиками:
В моих тестах самым быстрым был Underscore (но у него нет встроенного экранирования), потом мой велосипед (со всеми упомянутыми фичами), дальше «Javascript Micro-Templating» (тоже без экранирования), дальше Mustache.js (экранирование есть, но синтаксис на фигурных скобках вместо более привычных угловых с процентом, которые использует большинство шаблонизаторов). Это среди тех, у кого есть поддержка циклов.
Дальше, кроме скорости движки обычно отличаются некоторыми важными характеристиками:
- Поддержка циклов внутри шаблона. Как правило простые шаблонизаторы без этой фичи самые маленькие и быстрые… пока не доходит до вывода массива данных — в этот момент они начинают проигрывать по скорости примерно на порядок, а вывод массивов это абсолютно типичная операция.
- Встроенная поддержка экранирования подставляемых значений. На экранирование уходит дополнительное время, так что сравнивать шаблонизаторы с это фичей и без не совсем корректно. В то же время, на мой взгляд, это критическая фича — люди ленивы, и если вас волнует безопасность и отсутствие XSS в проекте, то шаблонизатор по умолчанию должен всё экранировать, а для отключения экранирования (что требуется довольно редко) должны требоваться дополнительные усилия.
- Удобство при разработке и отладке. Например, фича выдающая ясные сообщения об ошибках в синтаксисе шаблонов может сэкономить кучу времени, особенно если шаблонов на странице несколько и они не такие тривиальные.
В моих тестах самым быстрым был Underscore (но у него нет встроенного экранирования), потом мой велосипед (со всеми упомянутыми фичами), дальше «Javascript Micro-Templating» (тоже без экранирования), дальше Mustache.js (экранирование есть, но синтаксис на фигурных скобках вместо более привычных угловых с процентом, которые использует большинство шаблонизаторов). Это среди тех, у кого есть поддержка циклов.
что за велосипед?
Вообще-то я его пока не собирался выкладывать, к сожалению не во всех браузерах удалось получить номер строки, где при eval-е была обнаружена ошибка. Но скрывать там тоже нечего, так что смотрите: pastebin.ca/1991023 (мы в последних проектах этот шаблонизатор используем под довольно большой нагрузкой).
если говорить по поводу шаблонных движков на JS, мне больше нравится PURE т.к. в нем отображение и логика полностью разделены
что за велосипед?
остался доволен тем, что выбрал tmpl от джона ресига в свое время, хотя и пришлось конкретно все переделать, но во-первых скорость в 10 раз быстрее, а во-вторых на этот шаблонизатор не забьют
Sign up to leave a comment.
Тестирование производительности jQuery Templates