Comments 73
Скорее людям нужны возможности фреймворка, чем быстрота. Поэтому Peppy и подобные будут мало востребованы, так как мало плагинов, а значит и быстрого наращивания функциональности. Мне кажется авторам, которые ведут исследования в областях ускорения выбора элементов и т.д. лучше направить свои усилия на ускорение распространенных фреймворков(Prototype, jQuery и т.д.).
может быть. Я вот лично склоняюсь к тому мнению, что на рынке должно быть разнообразие: хочется готовый фремворк — используй jQuery, YUI, Prototype или Mootools. Хочешь чего-то более базового и быстрого (например, для крупного портала или внутристудийных разработок) — собери систему «по кирпичикам». Чтобы это не развалилось, когда захудалый склад станет небоскребом (видел пару таких примеров, где спасет полный снос текущей клиентской архитектуры).
НЕ согласен. У меня дома (1,6ГГц, IE6) хабр (да и многие другие проекты на jQuery) сильно притормаживает при открытии, а тут, глядишь, пошутсрее могли бы бегать :)
UFO just landed and posted this here
ну ты традиционно ускоряешь не в том месте =)
1. split может принимать на вход регулярку.
2. как быть в случае, если нужно выбрать элемент из поддерева?
3. как выбрать, например, все чекбоксы?
4. код не расширяем, не обманывай себя. css2 сюда фиг добавишь
5. если пользователю потребуется закэшировать — он просто создаст локальную переменную — это на порядок быстрее любых ухищрений с селекторами и удобнее их копипаста.
6. почему нет кэширования откомпилированной версии селектора? ах, у тебя же нет компиляции… а в base2 — есть.
1. split может принимать на вход регулярку.
2. как быть в случае, если нужно выбрать элемент из поддерева?
3. как выбрать, например, все чекбоксы?
4. код не расширяем, не обманывай себя. css2 сюда фиг добавишь
5. если пользователю потребуется закэшировать — он просто создаст локальную переменную — это на порядок быстрее любых ухищрений с селекторами и удобнее их копипаста.
6. почему нет кэширования откомпилированной версии селектора? ах, у тебя же нет компиляции… а в base2 — есть.
1. Спасибо. Да, тут надо проверить, что быстрее — split c регуляркой или replace с функцией.
2. Принимать поддерево в качество параметра можно. Хорошее замечание.
3. CSS2 — да, стоит добавить (выбор по атрибутам и проч.)
4. В данный момент не расширяем (будет точно сыпаться на > ). Но все можно переписать с нуля :)
5. Каждый раз кэшировать? Не проще ли выбирать элемент и не думать о том, закэширован он уже где-то или нет? Кэширование будет обламываться только в случае изменения дерева. Если у нас есть ключевые узлы — да, мы можем их закэшировать. А можем и просто выбирать
6. Что такое «откомпилированная версия»? Чем она отличается от строки и набора узлов?
А насчет «не того места» :) Выложу, наверное, в скором будущем анализ крупной системы на Mootools — там полетела именно сборка мусора и выбор элементов. И терялось на этом все 2-3 секунды в IE при открытии каждой страницы
2. Принимать поддерево в качество параметра можно. Хорошее замечание.
3. CSS2 — да, стоит добавить (выбор по атрибутам и проч.)
4. В данный момент не расширяем (будет точно сыпаться на > ). Но все можно переписать с нуля :)
5. Каждый раз кэшировать? Не проще ли выбирать элемент и не думать о том, закэширован он уже где-то или нет? Кэширование будет обламываться только в случае изменения дерева. Если у нас есть ключевые узлы — да, мы можем их закэшировать. А можем и просто выбирать
6. Что такое «откомпилированная версия»? Чем она отличается от строки и набора узлов?
А насчет «не того места» :) Выложу, наверное, в скором будущем анализ крупной системы на Mootools — там полетела именно сборка мусора и выбор элементов. И терялось на этом все 2-3 секунды в IE при открытии каждой страницы
6. тем, что «откомпилированный селектор» — это функция, максимально эффективно реализующая поиск элементов по заданному селектору.
7. конечно, код написанный через задницу проще оптимизировать в одном месте, чем переписывать во многих =) но если код пишется по уму — от «оптимизаций» в селекторах только вред.
7. конечно, код написанный через задницу проще оптимизировать в одном месте, чем переписывать во многих =) но если код пишется по уму — от «оптимизаций» в селекторах только вред.
хмм, наверное, дерево выбора самой быстрой функции для заданного селектора и есть его «компиляция». Просто с понятием не сталкивался (в частности, если #id задан — то сразу берется document.getElementById, и ничего дальше не предпринимается). Я на это и ориентируюсь. Просто сейчас не самая оптимальная реализация предложена.
7. Как показывает практика, обычно «пишется по уму» другой код, который основан на этих самых селекторах. А когда оказывается, что тормозит ядро, а чтобы его переписать, надо выкинуть 100Кб чужого кода… No comments :)
7. Как показывает практика, обычно «пишется по уму» другой код, который основан на этих самых селекторах. А когда оказывается, что тормозит ядро, а чтобы его переписать, надо выкинуть 100Кб чужого кода… No comments :)
у тебя парсинг селектора происходит при каждом запросе (кроме случаев попадания в кэш). в то время как результат этого парсинга можно закэшировать намертво.
7. это всё от мании реализовывать именно css селекторы. получается медленно и громоздко. у меня где-то валялась реализация не-цсс-селекторов, ориентированная именно на яваскрипт, с компиляцией, модульностью маленьким размером и тп… могу выложить, если интересно.
7. это всё от мании реализовывать именно css селекторы. получается медленно и громоздко. у меня где-то валялась реализация не-цсс-селекторов, ориентированная именно на яваскрипт, с компиляцией, модульностью маленьким размером и тп… могу выложить, если интересно.
выложи, интересно.
а, имеется в виду — промежуточный кэш для каждой части селектора? Это интересно.
выложи, плиз.
выложи, плиз.
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 )
функция jpath принимает на вход селектор и возвращает функцию, которая по переданному массиву ( по умолчанию — [document] ) строит новый массив.
там реализованы следующие субселекторы:
* свойство каждого объекта по имени: jpath(' .nodeName ')( document.images )
* элементы по идентификатору из каждого поддерева в массиве: jpath(' #anyId ')([ top, self ])
* элементы-потомки по имени тэга: jpath(' %p ')()
* дочерние элементы с опциональной фильтрацией по имени узла: jpath(' /td ')()
* фильтрация списка по имени класса: jpath(' :favorited ')( elements )
* фильтрация списка по jpath-селектору,
* фильтрация списка по значению: jpath(' [ .checked =«true» ] ')( checkboxes )
Интересное начинание.
Лично мне, правда, идея сильно напоминает base2, но, тем не менее, автор прав — от конкуренции и обилия инструментов все только выиграют. Да и мини-ядро в больших приложениях также лучше фреймворка.
Лично мне, правда, идея сильно напоминает base2, но, тем не менее, автор прав — от конкуренции и обилия инструментов все только выиграют. Да и мини-ядро в больших приложениях также лучше фреймворка.
Хотелось бы увидеть долю «оптимизированного» времени в жизненном цикле запроса. Проще говоря, сколько выигрываем вообще, начиная от нажатия на ссылку?
Забыл описание для ленивых:
«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»
«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»
Peppy быстрее, чем Sizzle
jamesdonaghue.com/?p=40
jamesdonaghue.com/?p=40
возник вопрос, что предпочтительнее выигрыш в скорости на 10-20% или возможность использовать CSS2- и CSS3-селекторы?
лично для меня предпочтительнее второе, поэтому я жду обновления YASS, которое бы реализовало такую поддержку :)
лично для меня предпочтительнее второе, поэтому я жду обновления YASS, которое бы реализовало такую поддержку :)
(в идеале, даже быстрее), чем нативные вызовы
Почему-то, когда вижу слово «нативный», желание читать пропадает. ;-)
Почему-то, когда вижу слово «нативный», желание читать пропадает. ;-)
а мне просто удвительно, как может быть быстрее чем нативно))
Для непонявших: переводить native как «нативный» — всё равно что вместо «книжный магазин» говорить что-нибудь типа «бучный шоп».
а как правильно переводить?
Родной, встроенный; зависит от контекста.
«родные вызовы», «встроенные вызовы»
фигня-с
фигня-с
Вызов встроенного метода.
встроенного во что?
В JavaScript-интерпретатор браузера, куда ж ещё. ;-)
нет, интерпретатор ничего такого не умеет. умеет это отдельная библиотека, реализующая ДОМ. но «метод встроен в библиотеку» — так тоже не говорят.
UFO just landed and posted this here
Посмотрите вот этот документ: code.msdn.microsoft.com/ie8whitepapers/Release/ProjectReleases.aspx?ReleaseId=574
думаю, он может быть полезен для оптимизации.
думаю, он может быть полезен для оптимизации.
Хохо, мерицо скоростью CSS1 vs CSS3+XPath — круто :)
Спасибо за бессонные ночи ;) То что нужно!
Есть просто проекты, на которых и вовсе не нужен никакой джфреймворк, а вот такого yass не хватает ;)
Есть просто проекты, на которых и вовсе не нужен никакой джфреймворк, а вот такого yass не хватает ;)
Кстати, а что думаете по поводу Sizzle?
doc['querySelectorAll'] проще записывается как doc.querySelectorAll, а разницы никакой, то же самое и для других методов
очень не рекомендую использовать подчёркивание в глобальном объекте, у доллара вначале тоже не было конфликтов
очень не рекомендую использовать подчёркивание в глобальном объекте, у доллара вначале тоже не было конфликтов
а быстрее ли? предварительные тесты показали, что так чуть быстрее. Руки не доходят каждую фичу в отдельности тестить :)
ммм? я про скорость не говорил: )
а эта библиотечка только ради скорости. По SlickSpeed делает все, что можно, раза в два :)
погоди, ты что ли имеешь в виду, что a['b'] быстрее, чем a.b?
по моему, немного быстрее
а по моим тестам — наоборот. На миллионе прогонов:
84 ms — a.b
134 ms — a['b']
84 ms — a.b
134 ms — a['b']
ну, вот и замечательно. Значит, исправлю обратно )
оказалось, что есть еще метод getElementsByClassName :)
Вдобавок не понятно, кто не прав в тестах — я или остальные библиотеки
yass.webo.in/slickspeed/?base2_1-0b2/Peppy_0-1/DOMAssistant_2-7-4/yass_0-1-3
По CSS1-тестам получается в 4 раза быстрее той же Peppy
оказалось, что есть еще метод getElementsByClassName :)
Вдобавок не понятно, кто не прав в тестах — я или остальные библиотеки
yass.webo.in/slickspeed/?base2_1-0b2/Peppy_0-1/DOMAssistant_2-7-4/yass_0-1-3
По CSS1-тестам получается в 4 раза быстрее той же Peppy
и так во всех браузерах
интересно: mootools.net/blog/2008/12/04/sizzle/
Честно говоря, здесь кэш вообще неправильно использовать. Ну разве что если специально будут указывать:
Просто страница может измениться, а элементы вернутся прежние
_('a', true);
Просто страница может измениться, а элементы вернутся прежние
Sign up to leave a comment.
Yet Another cSS selector = YASS