Yet Another cSS selector = YASS

[DisDis]

Скорее людям нужны возможности фреймворка, чем быстрота. Поэтому Peppy и подобные будут мало востребованы, так как мало плагинов, а значит и быстрого наращивания функциональности. Мне кажется авторам, которые ведут исследования в областях ускорения выбора элементов и т.д. лучше направить свои усилия на ускорение распространенных фреймворков(Prototype, jQuery и т.д.).

[sunnybear]

может быть. Я вот лично склоняюсь к тому мнению, что на рынке должно быть разнообразие: хочется готовый фремворк — используй jQuery, YUI, Prototype или Mootools. Хочешь чего-то более базового и быстрого (например, для крупного портала или внутристудийных разработок) — собери систему «по кирпичикам». Чтобы это не развалилось, когда захудалый склад станет небоскребом (видел пару таких примеров, где спасет полный снос текущей клиентской архитектуры).

[RomanL]

НЕ согласен. У меня дома (1,6ГГц, IE6) хабр (да и многие другие проекты на jQuery) сильно притормаживает при открытии, а тут, глядишь, пошутсрее могли бы бегать :)

[sunnybear]

да, спасибо, есть еще пара мест для оптимизации — типа все, что можно, закэшировать.
И по поводу регулярки еще не смотрел, какая реализация быстрее. Да еще и в каких браузерах :)

[sunnybear]

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

По поводу ajax — это же мини-ядро :) Сюда еще методы изменения узлов нужны, ajax, события, таймеры, массивы и проч…

[tenshi]

ну ты традиционно ускоряешь не в том месте =)

1. split может принимать на вход регулярку.
2. как быть в случае, если нужно выбрать элемент из поддерева?
3. как выбрать, например, все чекбоксы?
4. код не расширяем, не обманывай себя. css2 сюда фиг добавишь
5. если пользователю потребуется закэшировать — он просто создаст локальную переменную — это на порядок быстрее любых ухищрений с селекторами и удобнее их копипаста.
6. почему нет кэширования откомпилированной версии селектора? ах, у тебя же нет компиляции… а в base2 — есть.

[sunnybear]

1. Спасибо. Да, тут надо проверить, что быстрее — split c регуляркой или replace с функцией.
2. Принимать поддерево в качество параметра можно. Хорошее замечание.
3. CSS2 — да, стоит добавить (выбор по атрибутам и проч.)
4. В данный момент не расширяем (будет точно сыпаться на > ). Но все можно переписать с нуля :)
5. Каждый раз кэшировать? Не проще ли выбирать элемент и не думать о том, закэширован он уже где-то или нет? Кэширование будет обламываться только в случае изменения дерева. Если у нас есть ключевые узлы — да, мы можем их закэшировать. А можем и просто выбирать
6. Что такое «откомпилированная версия»? Чем она отличается от строки и набора узлов?

А насчет «не того места» :) Выложу, наверное, в скором будущем анализ крупной системы на Mootools — там полетела именно сборка мусора и выбор элементов. И терялось на этом все 2-3 секунды в IE при открытии каждой страницы

[tenshi]

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

7. конечно, код написанный через задницу проще оптимизировать в одном месте, чем переписывать во многих =) но если код пишется по уму — от «оптимизаций» в селекторах только вред.

[sunnybear]

хмм, наверное, дерево выбора самой быстрой функции для заданного селектора и есть его «компиляция». Просто с понятием не сталкивался (в частности, если #id задан — то сразу берется document.getElementById, и ничего дальше не предпринимается). Я на это и ориентируюсь. Просто сейчас не самая оптимальная реализация предложена.

7. Как показывает практика, обычно «пишется по уму» другой код, который основан на этих самых селекторах. А когда оказывается, что тормозит ядро, а чтобы его переписать, надо выкинуть 100Кб чужого кода… No comments :)

[tenshi]

у тебя парсинг селектора происходит при каждом запросе (кроме случаев попадания в кэш). в то время как результат этого парсинга можно закэшировать намертво.

7. это всё от мании реализовывать именно css селекторы. получается медленно и громоздко. у меня где-то валялась реализация не-цсс-селекторов, ориентированная именно на яваскрипт, с компиляцией, модульностью маленьким размером и тп… могу выложить, если интересно.

[voicer]

выложи, интересно.

[sunnybear]

а, имеется в виду — промежуточный кэш для каждой части селектора? Это интересно.

выложи, плиз.

[tenshi]

pastebin.mozilla-russia.org/93256

функция jpath принимает на вход селектор и возвращает функцию, которая по переданному массиву ( по умолчанию — [document] ) строит новый массив.

там реализованы следующие субселекторы:
* свойство каждого объекта по имени: jpath(' .nodeName ')( document.images )
* элементы по идентификатору из каждого поддерева в массиве: jpath(' #anyId ')([ top, self ])
* элементы-потомки по имени тэга: jpath(' %p ')()
* дочерние элементы с опциональной фильтрацией по имени узла: jpath(' /td ')()
* фильтрация списка по имени класса: jpath(' :favorited ')( elements )
* фильтрация списка по jpath-селектору,
* фильтрация списка по значению: jpath(' [ .checked =«true» ] ')( checkboxes )

[sunnybear]

а тесты производительности какие-нибудь есть? А то ведь можно исходный селекторо перевести в jpath…

[tenshi]

нет, конечно =) меня вопросы производительности слабо волнуют. гибкость — превыше всего! ;-)

[voicer]

Интересное начинание.
Лично мне, правда, идея сильно напоминает base2, но, тем не менее, автор прав — от конкуренции и обилия инструментов все только выиграют. Да и мини-ядро в больших приложениях также лучше фреймворка.

[voicer]

Да, забыл добавить — успехов в новом проекте :)

[ofigenn]

Хотелось бы увидеть долю «оптимизированного» времени в жизненном цикле запроса. Проще говоря, сколько выигрываем вообще, начиная от нажатия на ссылку?

[sunnybear]

боюсь, время на запрос будет зависеть от специфики библиотеки. Т.е. самое быстрое сейчас — это концепция. Все остальное — просто примочки, которые ее чуть-чуть тюнят.

[ofigenn]

Это я к тому, что ты написал: «В ближайшее время я планирую провести ряд исследований...»! Если будет интерес, посчитай и этот параметр. Для общей оценки он важен, я думаю.

[IIIEB4YK]

github.com/jeresig/sizzle

[IIIEB4YK]

Забыл описание для ленивых:
«This is a new pure-JavaScript CSS selector engine that I'm working on.

Comes in at roughly 4x faster in Firefox 3, 3x faster in Opera 9, 1.5x faster in Safari 3 than the other major
JavaScript libraries. It's completely standalone (no library dependencies) and clocks in at 4KB.

Currently this engine is expected to become the new default selector engine of jQuery, MochiKit, Prototype, and Dojo»

[sunnybear]

Peppy быстрее, чем Sizzle
jamesdonaghue.com/?p=40

[XaocCPS]

возник вопрос, что предпочтительнее выигрыш в скорости на 10-20% или возможность использовать CSS2- и CSS3-селекторы?
лично для меня предпочтительнее второе, поэтому я жду обновления YASS, которое бы реализовало такую поддержку :)

[the_buddha]

Ты прав брат, но imho многие ждут обратного, в плане что бы уже существующие мйнстримовые фреймворки ускорялись)) а я так вообще молюсь что окгда ибудь вс ебраузеры будут поддерживать нативные css3 селекторы

[MTonly]

(в идеале, даже быстрее), чем нативные вызовы
Почему-то, когда вижу слово «нативный», желание читать пропадает. ;-)

[the_buddha]

а мне просто удвительно, как может быть быстрее чем нативно))

[sunnybear]

может быть :) причем в наиболее быстрых браузерах — Safari, Opera, Chrome: именно в них элементарные операции «отъедают» меньше, а DOM сильно не пооптимизируешь :)

[MTonly]

Для непонявших: переводить native как «нативный» — всё равно что вместо «книжный магазин» говорить что-нибудь типа «бучный шоп».

[tenshi]

а как правильно переводить?

[MTonly]

Родной, встроенный; зависит от контекста.

[tenshi]

«родные вызовы», «встроенные вызовы»

фигня-с

[MTonly]

Вызов встроенного метода.

[tenshi]

встроенного во что?

[MTonly]

В JavaScript-интерпретатор браузера, куда ж ещё. ;-)

[tenshi]

нет, интерпретатор ничего такого не умеет. умеет это отдельная библиотека, реализующая ДОМ. но «метод встроен в библиотеку» — так тоже не говорят.

[sunnybear]

:) пока тут продолжается дискуссия, библиотеку удалось ускорить еще в два раза :) в ночь выложу версию 0.1.6

[MTonly]

Энтузиазм при наличии свободного времени — это замечательно. ;-)

[sunnybear]

особенно, без наличия оного :)

[MTonly]

Со временем это проходит. ;-)

[sunnybear]

там сложная функция, линейная :)

[MTonly]

Хорошо, движок JavaScript. ;-)
В любом случае нативный — туда же, куда и лочить вместо блокировать.

[tenshi]

меня пугают слова длиннее 7 букв…

[MTonly]

Волков бояться — в лес не ходить. ;-)

[tenshi]

есть такая, 100кб весом.

[bolk]

Посмотрите вот этот документ: code.msdn.microsoft.com/ie8whitepapers/Release/ProjectReleases.aspx?ReleaseId=574
думаю, он может быть полезен для оптимизации.

[sunnybear]

спасибо. Там речь идет о querySelectorAll — он уже добавлен в самое начало. Safari 3 уже поддерживает

[bolk]

IE8b тоже уже поддерживает. Я подробно ваш код не смотрел, глянул краем глаза, поэтому не видел, что вы уже поддерживаете Selector API.

[z_z]

Хохо, мерицо скоростью CSS1 vs CSS3+XPath — круто :)

[deerua]

Спасибо за бессонные ночи ;) То что нужно!
Есть просто проекты, на которых и вовсе не нужен никакой джфреймворк, а вот такого yass не хватает ;)

[VasilioRuzanni]

Кстати, а что думаете по поводу Sizzle?

[arty]

doc['querySelectorAll'] проще записывается как doc.querySelectorAll, а разницы никакой, то же самое и для других методов

очень не рекомендую использовать подчёркивание в глобальном объекте, у доллара вначале тоже не было конфликтов

[sunnybear]

а быстрее ли? предварительные тесты показали, что так чуть быстрее. Руки не доходят каждую фичу в отдельности тестить :)

[arty]

ммм? я про скорость не говорил: )

[sunnybear]

а эта библиотечка только ради скорости. По SlickSpeed делает все, что можно, раза в два :)

[arty]

погоди, ты что ли имеешь в виду, что a['b'] быстрее, чем a.b?

[sunnybear]

по моему, немного быстрее

[arty]

а по моим тестам — наоборот. На миллионе прогонов:
84 ms — a.b
134 ms — a['b']

[sunnybear]

ну, вот и замечательно. Значит, исправлю обратно )
оказалось, что есть еще метод getElementsByClassName :)
Вдобавок не понятно, кто не прав в тестах — я или остальные библиотеки
yass.webo.in/slickspeed/?base2_1-0b2/Peppy_0-1/DOMAssistant_2-7-4/yass_0-1-3

По CSS1-тестам получается в 4 раза быстрее той же Peppy

[arty]

про неправ я не понял

кстати, в тестах с id-селекторами в опере ошибки — именно с yass

[sunnybear]

спасибо, посмотрю Opera чуть позже: тяжело несколько веток сразу вести, а потом сливать наиболее продуктивные

[tenshi]

до округления:
а) .49 .49 .49 .49
б) .51 .51 .51 .51
а быстрее б на 4%

после округления:
а) 0 0 0 0
б) 1 1 1 1
а быстрее б на бесконечное число процентов

[sunnybear]

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

Про 0-0-0-0 я вообще молчу. Тут даже сравнивать не с чем — просто быстрее, и все :)

[arty]

и так во всех браузерах

[f33l]

интересно: mootools.net/blog/2008/12/04/sizzle/

[Keyten]

Честно говоря, здесь кэш вообще неправильно использовать. Ну разве что если специально будут указывать:

_('a', true);

Просто страница может измениться, а элементы вернутся прежние