Скорость Выбоки jQuery
 

Вот тут написал свой скрипт выборки подобный jQuery
Кто точно знает в сотых мс сколько занимает jQuery?
У меня вышло около 0.35мс на выборку. #ID вообще 0.05мс занимает. остальное повышение занимает длина выборки (точнее от длины выборки время фактически не зависит) и количество элементов в выборке.

Выборку чего, каким CSS-селектором? Да и о каких точных результатах может идти речь, если у всех разная производительность компьютеров и браузеров?

http://slickspeed.googlecode.com/

ну вот пример
http://lusever.ru/css-selectors/webo.in/
показывает 0мс 1мс и т.п. нет точности до тысячных.
СSS селектор был "B,#123 A#123,DIV,.test" среди около 100 элементов при повторении 10000 раз.

Для сравнения системы на базе Intel Atom Z520 и Intel Core i7 720QM в Firefox 3.5.7.
http://yass.webo.in/slickspeed/?jQuery_1-3-2

мде далеко пойдем. это че за прикол?

Там просто по много раз запускается один и тот же тест

for (var i = 99; i; i--) {
				    				    $(selector);
				}

чтобы не было, как у lusever, когда в современных браузерах только результаты 1 и 0 мс.

дык я так и тестировал выше указанный селектор 10000 раз. в итоге #ID выдает 0.05мс а указанный 0.35-0.37мс. это все меньше 1мс.

А можно задать возможно глупый вопрос, как вы засекли время с точностью меньше мс в javascript? На сколько знаю в нем только с точностью до мс время узнать можно

общее время на количество повторов. получаем среднее время одного запроса в данном случае.
любая команда в js на моей машине выполняется в 0.004мс.

получается у jQuery выборка по #ID занимает 3 мс / 100 итераций = 0.03 мс а у вас 0.05 :) пока jQuery выигрывает.

П.С. У меня кстати тоже была идея попробовать свою выборку реализовать так ради исследования и баловства ))

Я еще до конца не оптимизировал. + Вы сравниваете мою машину и вашу. И еще не известно в каком браузере. На моей машине #ID с jQuery ~ равны. И в данном случае я планирую сделать такие выборки которые jQuery не по зубам. Или по зубам но они будут долгими. Когда реализую, отпишу возможности время выполнения и ~ размер кода

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

Скрипт еще в разработке но могу уже привести некоторые результаты

вот такой селектор

TABLE#`child` >(:2,4:6,8:) (((DIV:#(:-10,-4:-2,-0) ~-1:2)(B,A({title!=`Гыгы`i},[height='100px'])),U){title=`^До\`бро`i}) +2, SPAN.!`window`i <1:4 A

раскладывается на 31 комбинацию селекторов за:
0.0023мс в Chrome,
0.0063мс в MZ,
0.01мс Opera,
0.9мс в Safari
5-6мс в IE8

Селектор составлен хатично для показа максимума. Планируется ввести выборку по регулярке(`JSRegExp`[igm]), по атрибутам, свойствам и значениям стилей. Также в командах >,+, и новой задуманной мной < есть уровни вложенности проверок. Например, одна из возможностей, "TABLE >3:6 A" будет искать все A которые находятся в TABLE и уровень родителя TABLE не ближе 3 и не дальше 6. Позже распишу подробнее.

только кто, кроме тебя, захочет разбираться в каком-то новом хитром синтаксисе селекторов, когда стандартизированных CSS и XPath больше чем достаточно? :)

именно. он не нов. а расширен. все что умеет jQuery будет иметь и мой.

PeaceCoder,
а зачем такие селекторы вообще нужны?

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

Да я хз. Мне tagName+className без каскадов всегда хватало. А вот такие сложные так вообще не могу представить где бы понадобились.

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

$('#someid .clazz[attr=some]').each(function() {
  var $this = $(this);
  if ($this.is('...selector...') {
    $this.find('...another..selector...')...
    ...
  } else {
    ...
  }
})

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

плиз приведите пример из практики именнос с точными названиями селекторов. хочу попробовать сэмулировать "мой" запрос не прибегая к таким вот ухищрениям.
ощутимо хуже. на порядок точно т.к. для каждого полученного элемента Вы проверяете не является ли он чемто + создаете новый обьект с новым запросом и не факт того, что будет хоть какой то результат. а если резултата нет, время между первым и запросом и обработкой "духов" потрачено впустую (все команды each)

ну, по-моему, очевидно. Чтобы можно было сказать: "А вот мой фреймворк..."

мне это напомнило легенду о мастерах Мурамаса и Масамунэ

плохое сравнение. я же не делаю то что быдет хуже jQ а наоборот.
Вот еще один пример применения новой команды.
Допустим есть блок в котором хаотично расположены элементы с нужным классом. И допустим в этих элементах куча других элементов. Сколько их неизвестно. Задача: нужно, например, чтото делать с элементом нужного класса (необязательно :hover|:active изменение стилей), когда мышью водят/кликают над этим элементом при этом надо получить этот элемент и не факт что в этом спец элементе не будет такого же спец элемента. как вы будете решать такую задачу ? а выбрать надо всего 1 нужный блок причем с определенными параметрами

<div id='блок'>
хаотично расположенные элементы (много, в том числе и спец блоки с нужным классом)
  <div class="нужныйБлок">
  тут куча элементов и детей + тут тоже могут быть теже "нужные блоки"
  </div>
  ...
</div>

Когда говорится, что селекторы не нужны, имеется в виду, что они не нужны при нормальной вёрстке. А если по-хорошему верстать, то и в самом CSS-то каскады не нужны, не то, что в JavaScript.

Я уж не говорю о том, что никаких #id-шников в CSS быть не должно, хоть это к теме и не относится, больной вопрос у меня просто :)

почему? (в смысле быть не должно)

У селекторов с #id очень высокий вес и их практически невозможно перебить селектором без какого-нибудь #id. Попадаются умники, которые каскады из #id-шников делают. Теперь представь ситуацию, верстальщик понаписал правил для списков, вроде

#page #content ul { list-style-type: none; }

А тебе понадобилось на одной странице сделать список с буллетами. Ты не сможешь просто написать

.mylist { list-style-type: circle; }

Точнее сначала ты такое напишешь, потом будешь разбираться, почему не работает, потом обнаружишь, что вышестоящее правило в 20 раз сильнее, и чтобы его перебить, тебе нужно добавить в селектор еще 2 #id-шника. А если нужно сделать специфический блок, которые может находится в любом месте страницы, то всё становится ещё хуже.

Kolyaj спасибо.

Хе хе. а в jQ боооольшой баг =)))
создал документик с 1 DIV#id123
и сделал такую выборку

alert('Элемент #id1234567890 в документе '+(document.getElementById('id1234567890') ? '':'не')+'существует');
T=(new Date()).getTime();

  for (i=0;i<1000;i++) $('#id1234567890 TABLE DIV B A U B A TABLE DIV *');

  alert('Время выборки: '+((new Date()).getTime()-T)/1000+'ms');

Как вам такой баг? Вы еще пользуетесь jQ?

jQuery-ненавистнег

не. не ненависнег. просто оч много багов в нем. вот и сообщаю. много лишней работы делает.
Это видно по примеру. элемента нет а выборка занимает почти 1 мс в MZ. А ие там вообще загнется.
В связи с этим сейчас думаю как быстро пресечь вот такие вот баги.

вот например http://www.marimedia.ru/js/main.js
функция initTopMenu начиная со строки
$('#navigation .nav-item').each( function()
хотя пример не очень там внутри цикла кроме выборки еще и другая логика

В общем я не говорю, что вы зря этим занимаетесь, здесь в другом дело - как часто вообще люди применяют НАСТОЛЬКО сложные серекторы? нужно ли это? ведь как писали выше если нормально сверстано, то и запросы проще будут. и ваши выдуманные ужасные случаи когда там элемент затерялся среди других и его выцеплять надо чуть ли не по номеру строки в файле это такая редкость, что решать такие проблемы надо не такими же ужасными серекторами а изменением верстки.

Мне очень интересно что у вас получится.

то что уже получается я уже привел результаты. кстати баг с "пустышками" уже пресек.

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

И сайт ввиде текста без картинок ;) Если нет классов то inline стили? это плохой знак верстки.

все построено на <тег:спец_код>...</тег:спецкод>

нет, на <пространство_имён:локальн� �е_имя_тэга>

Не знал что так можно, это везде работает? (IE6?)

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

В чем преимущество такой верстки?

скорость и наглядность