1. Предисловие

Я бы хотел начать эту статью с цитаты Джона Ресига (John Resig), основного идеолога jQuery и корпорации Mozilla.

Я думаю, вы переоцениваете полезность jQuery. Используя его пользователи теперь ограничены селекторами которые могут использовать (они могут использовать, только то, что предоставляет браузер и полагаться на милость кросс-браузерных багов) и это большая проблема. Не говоря уже о том что jQuery призывает к смешиванию html разметки, css и javascript.

В этой статье я хочу показать что в умелых руках и хуй - балалайка.

Итак начнем настраивать наш... инструмент с самого начала.

2. Selectors

Начну, пожалуй, с самого начала с функции $, она принимает два параметра: первый - селектор, второй - контекст. Хотя контекст обычно опускают я в последствии покажу как им грамотна пользоваться.

2.1. Простой селект

Самый простой вариант это выбор по id, имени тега и имени класса.

$("#id")
$("tag")
$(".class")

Я не случайно расположил их именно в такой последовательности, они идут по сложности алгоритма выборки. В первом случаи вызов функции эквивалентен вызову:

document.getElementById("id");

Поскольку предполагается что id уникальный то поиск проходит очень быстро, и если на странице есть два элемента с таким id то найден будет только первый. Хот я в IE и тут накосячили и до 7 версии включительно в случаи отсутствия элемента с таким id он вернет элемент у которого совпадает атрибут name.

Во втором случаи тоже всё относительно просто:

document.getElementsByTagName("tag");

Получили все ноды с таким именем из документа и все готово. И на удивление никаких косяков, если не учитывать что при запросе getElementsByTagName("*") IE вернет и комментарии тоже.

В третьем случаи если есть возможность работу перехватывает:

document.getElementsByClassName("class");

(Табличку поддерживаемости этой функции смотрите на quirksmode.org)

Но эту функцию поддерживают уже не все браузеры. Для остальных применяется совсем другой алгоритм - нужно получить абсолютно все ноды, потом обойти их циклом проверяя имена классов, и если совпали то добавить в массив результата.

var nodes = document.getElementsByTagName("*"), result = [];
for (var i=0; i<nodes.length; i++){
	if(" " + (nodes[i].className || nodes[i].getAttribute("class")) + " ").indexOf("class") > -1)
		result.push(nodes[i]);
}

Какой метод использовать определяется в самом начале при подключении библиотеки.

2.2. Селекст через querySelectorAll

Но это все подходит только для элементарных селекторов. А на практике приходится обычно использовать намного более сложные конструкции. И для них в современных браузерах FireFox 3.0, Safari 3.2, Opera 9.5 в том числе и в IE8 появились функция querySelector и querySelectorAll. Они соответственно предназначены для поиска одной или нескольких нод по CSS3 селекторам. Если браузер клиента поддерживает эту функцию то все о чем мы говорили в прошлом пункте - отпадает и поиск происходит через querySelectorAll.

$("#id .class tag")

В лучшем случаи селектор будет обработан именно querySelectorAll потому что он написан по правилам CSS3. Но так можно не со всеми селекторами, jQuery поддерживает ряд селекторов которые не входят в CSS3 такие, например, как :visible.

$("#id .class tag:visible")

Такой селектор выдаст ошибку в функции querySelectorAll и селектор будет перенаправлен в поисковый движок Sizzle где строка будет разбита на простые селекторы и превратится по сути в несколько разных поисков в котором каждым следующим контекстом является предыдущий селектор.

$(document).find("#id").find(".class").find("tag").filter(":visible")

Скорость этого метода поиска напрямую зависит от величины DOM дерева, чем оно больше - тем медленнее, но её можно значительно увеличить написав селектор раздельно.

$("#id .class tag").filter(":visible")

При этом querySelectorAll выберет все ноды, а Sizzle разберется с ":visible"

По поводу псевдо-селекторов тоже кстати очень интересный вопрос: CSS3 поддерживает несколько видов псевдо-классов такие как :nth-of-type/:nth-child/:parent/:not/:checked , jQuery имеет свою реализацию этих селекторов для браузеров не поддерживающих querySelectorAll или для браузеров в которых querySelectorAll не поддерживает данный селектор (табличку поддерживаемости селекторов смотрите на quirksmode.org), но эта реализация иногда отличается. Для примера возьмем псевдо-класс :nth-of-type и выберем все четные дивы а из них все нечетные.

document.querySelectorAll("div:nth-of-type(even):nth-of-type(odd)") // Safari/FireFox:0  IE/Opera:N/A
$("div:nth-of-type(even):nth-of-type(odd)"); // Safari/FireFox:0  IE/Opera:All
$("div:even:odd"); // All: вернут 1,5,9 дивы 

Первых два примера работают одинаково и вернут либо 0, если отработала функция querySelectorAll (это касается первого примера), либо все элементы, потому что их обработал Sizzle (это особенность реализации выражения ":"), а третий вернет 1, 5, 9 и тд. элементы, а значит селекторы отрабатывали в три прохода, сначала из всего дом дерева были выбраны все дивы, потом из них были выбраны все нечётные, а потом из оставшихся были выбраны все чётные.

jQuery так же имеет набор псевдо-селекторов который не входят в CSS3 и обслуживаются только Sizzle'ом :visible/:animated/:input/:header. Их лучше выделять отдельно так как они могут сильно замедлить выборку. Так например было с селекторами :visible/:hidden в версии 1.2.6, для того чтобы узнать видимый элемент или нет надо было подняться до самого верха по DOM-дереву проверяя атрибуты display и visible каждого родителя. [пруфлинк]

$("div").filter(":visible")

Псевдо-классы используемые для поиска элементов формы такие как :radio тоже имеют некоторое преимущество если не используется querySelectorAll в противном случаи CSS3 селектор input[type=radio] работает быстрее

2.3. Сложенный селект

Сложенный селект это когда нам надо выбрать группу из двух или более разных селекторов, например все дивы у которых класс равен A, B и C

Это можно сделать двумя способами

$(".a,.b,.c")

выбрать все сразу

$(".a").add(".b").add(".c")

или по одному.

При этом если задействована функция querySelectorAll то первый быстрее второго в четыре раза, а если нет то второй в два раза быстрее первого.

Если уже заговорили про классы их можно искать как любые другие атрибуты например если надо найти все классы имена которых начинаются на "my" можно сделать так

$("[class^=my]")

а не городить логику с использованием add, тем более что такой способ поддерживается querySelectorAll. [пруфлинк]

2.4. Неправильный селект в контексте

На сайте tvidesign.co.uk в одной очень популярной статье "Improve your jQuery - 25 excellent tips" которую перевели на русский и перепечатывают где только не лень, начиная с Хабра, написано что селект лучше делать в контексте и приведен вот такой пример:

$('#listItem' + i, $('.myList'))

Я не спорю что Jon Hobbs-Smith иммет неплохое портфолио но тем не менее он ничего не знает о jQuery. Да и вообще статьи начинающиеся на "100-500 советов" попахивают несостоятельностью автора излагать свою мысль последовательно, не говоря уже о том что все эти советы Капитан Очевидность уже давно нам дал в мануалах, факах и руководствах.

Рассмотрим пример подробнее: контекст это то, где ищут селектор, значит пример можно переписать в более наглядную но менее читаемую форму

$($(".myList")).find("#listItem")

При этом контекст от первого поиска будет являться document.

$($(".myList",document)).find("#listItem")

Еще раз перепишу согласно формуле.

$($(document).find(".myList")).find("#listItem")

И наконец раскроем скобки

$(document).find(".myList").find("#listItem")

Что же получается мы выполняем дорогостоящую операцию поиска по имени класса (по всему DOM-дереву в худшем случаи) для того чтобы упростить и без того самую простую операцию поиска по id. БРЕД!

2.5. Правильный селект в контексте

Правильно делать с точностью да наоборот. В контекст надо указывать id элемента.

$(".class",$("#id"))

Только вот я не понимаю зачем вообще в контекст передавать jQuery объект вполне достаточно.

$(".class","#id")

Это можно переписать как.

$("#id").find(".class")

Можно еще больше ускорить работу, если искать вот таким способом:

$(document.getElementById("id")).find(".class")

Но это ИМХО будет уже плохим тоном. Хотя поэкспериментировать интересно, что если вместо getElementById взять querySelectorAll

$("div",document.querySelectorAll("#id"))

Это примерно тоже самое что и

$("div",[document.getElementById("id")])

Не прироста производительности ни красоты кода из этого не получить, поэтому советую в контекст передавать что-то простое вроде id или при использовании псевдо-селекторов обрабатываемых Sizzle'ом передавать их в селектор а все остальное в контекст

$(":visible","input[type=checkbox]")

Ну раз уже заговорили о псевдо-селекторах то

$(":checkbox")

быстрее чем

$("input[type=checkbox]")

без использования querySelectorAll и наоборот.

2.6. Cложный селест

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

$("#id > div")

Но если выборка уже есть то будем использовать ее как контекст. Как мы уже выяснили поиск в контексте происходит при помощи функции find

$("#id").find("> div")

Но find очень дорогая функция, она просматривает абсолютно всех потомков контекста, поэтому лучше использовать функцию children, она просматривает только непосредственных потомков.

$("#id").children("div")

Есть еще ряд функций поиска и манипуляций которых стоит избегать без крайней необходимости это: find, closest, wrap, wrapInner, replaceWith, clone. Заметте wrapAll сюда не входит. [пруфлинк]

3. Cache

3.1. Внутреннее кеширование

Кеш у jQuery крайне не развит, если не сказать отсутствует, поэтому кешируется только предыдущий элемент выбранный в цепочке. Это можно наглядно рассмотреть на двух примерах.

Ситуация такая, вы работаете со списком у вас если один из элементов li для того чтобы получить все элементы включая текущий надо выбрать всех братьев (все у кого родитель это родитель текущего) этого элемента и добавляем его самого

$("#id").siblings().add("#id")

Так как он - прошлый элемент, с которым работали в цепочке вызовов, мы можем взять его из кеша.

$("#id").siblings().andSelf()

Конечно в данном конкретном случаи быстрее было бы сделать

$("#id").parent().children()

Потому что siblings это и есть выбор всех детей родителя. Но я думаю что принцип использования этот пример иллюстрирует нормально.

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

var elt = $("#id");
elt.children().css({/**/})
elt.click();

Можно после работы с детьми вернуться обратно к родителю и работать с ним дальше

$("#id").children().css({/**/}).end().click()

3.2. Кеширование селекторов

Поскольку кеш так слабо развит, селекторы нужно кешировать вручную. Возьмем например вот такой код

for(var i=0;i<1000;i++)
	$("ul").append("<li>"+i+"</li>")

Все работает и выглядит красиво, но это можно оптимизировать если вынести выборку за пределы цикла добавление новых элементов будет проходить быстрее

var elts = $("ul");
for(var i=0;i<1000;i++)
	elts.append("<li>"+i+"</li>")

3.3. Буферизация

Но и это еще не все, этот код можно заставить работать еще быстрее. Каждый раз делая append мы заставляем обновиться DOM-дерево и заставляем браузер перерисовать страницу. Этого можно избежать придерживая вставку в DOM-дерево.

var str = "";
for(var i=0;i<1000;i++)
	str += "<li>"+i+"</li>"
$("ul").html(str);

Дело в том что функции для работы с DOM-деревом у jQuery самые "тяжелые" [пруфлинк]. Это просто объясняется. Все html ноды на которые повешены события через jQuery имею в себе атрибут с объектом jQuery. При удалении этих нод нужно следить чтобы не было утечек памяти и удаляет эти атрибуты перед удалением ноды. В результате функции html и text вызывают функции полной очистки и только потом вставки нового содержимого.

jQuery(DOMElement).empty().append(text)

Функция empty выбирает все ноды и по очереди удаяет

jQuery(DOMElement).children().remove()

А функция remove уже заботится чтобы из элементов были удалены все дополнительные данные и события

Джон Ресиг (John Resig) утверждал что знает способ быстро удалить все это и что улучшит эти методы, но что-то воз и ныне там. Поэтому будем ждать улучшенных функций уже в jQuery 1.4

3.4. Создание "на лету"

Прошлый пример на самом деле был нужен, для того что бы я подобрался поближе к интересненькому. Часто приходится создавать какие-то вспомогательные дивы, естественно меня заинтересовал самый эргономичный способ это сделать. Казалось бы в чем проблема кинул кусок html кода в и jQuery сама все сделала. Возьмем самый простой и банальный пример надо создать пустой див.

$("<div></div>")

или

$("<div/>")

Второй вариант в 5 раз быстрее первого. Но это естественно не все, что если нам надо создать не пустой див, а содержащий текст, из прошлых заметок станет ясно что функция text тяжелая и выгоды от нее не будет и стоит создавать див как есть.

$("<div>text</div>")

А не создавать а потом добавлять текст

$("<div/>").text("text")

Но это не каcается создания атрибутов, для них используются намного более "легкие" функции attr/css/addClass [пруфлинк], вот тут то и имеет смысл вместо

$("<div style='background:red;'/>")

писать

$("<div/>").css({background:'red'});

это даст небольшой, но выигрыш.

4. Events

4.1. Множественные события

Иногда возникает необходимость повесить одно и тоже действие на несколько событий, это приводит к созданию новых функций либо к копи-пасте. Этого легко можно избежать. Например нужно задать размер дива при загрузке и изменять его при изменении размеров окна.

$(window).bind("resize load",null,function(){
	$("#id").css({width:document.clientWidth})
});

Только при этом не забываем что IE8 ведет себя не корректно и при загрузке страницы сначала происходит событие resize а только потом load.

Тоже самое корректно и в обратную сторону.

$(window).unbind("resize load");

Но это не работает в версии 1.2.6, точнее это работает только с именованными функциями а с анонимными не работает, их надо удалять по одной.

4.2. Одно событие на много элементов

Если случается повесить события на длинный список.

var ul = $("<ul/>");
for(var i=0,j=1000;i<j;i++)
	$("<li>"+i+"</li>").click(function(e){
		alert(this.innerHTML);
	}).appendTo(ul);


ul.appendTo("body");

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

var str = "";
for(var i=0,j=1000;i<j;i++)
	str += "<li>"+i+"</li>";
$("<ul/>")
	.append(str)
	.click(function(e){
		alert(e.target.innerHTML);
	})
	.appendTo("body");

Но он затронул далеко не все методы, а только основные. Именно этим я сейчас и собираюсь заняться, я собираюсь пройтись по всей документации выписать методы и посмотреть какие методы и сколько времени работают. В общем работа не сложная но нудная. Скрипт замеров уже есть плюс FireUnit мне поможет. Записывать буду имя тестируемого метода, количество вызовов внутри него, соотношение количества внутренних вызовов к количеству выбранных элементов (O), среднее время. Если O меньше 2n, то оно не записывается и считается примерно равным одному n , а n == 40, потому что в примере участвует 40 дивов. Для примера была взята страницы выдачи результатов Google и чуть-чуть подправлена. Да и еще есть такие методы которые работаю только с первым элементом коллекции, в основном получают значение его параметров, для них вноситься отдельная правка.

Пример отрабатывает долго поэтому я вынес его в отдельный файл, смотрите чтоб не подвесил ваш браузер. Хотел сделать еще сравнение по версиям типа 1.3.2 vs 1.2.6 но последний даже не смог полностью отработать - виснет, поэтому предлагаю тем кому действительно интересно сохранить страницу поправить версию и запустить локально, закомментировав половину кода. И там еще какие-то глюки с replaceAll, вроде как из-за него виснет. Но могу сказать заранее, что хоть в более новой версии показатель О выше (больше вызовов функций на каждый элемент), но работает она в среднем быстрее.

И последние перед тем как я дам ссылку на пример его нужно смотреть в FireFox c установленным FireBug и FireUnit. А вот и ссылка на пример.

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

Первым я протестирую контекст, проверять буду вот таким скриптом

var start = new Date();
for(var i=0;i<1000;i++)
	$....
var stop = new Date();
console.log(stop-start)

Я не будем добавлять ничего нового к коду Google, а только попробуем собрать коллекцию li.

Вывод из первого эксперимента - сам по себе контекст это еще один поиск по DOM дереву, поэтому задавать контекст стоит только если второй запрос ограничит первый на столько что сэкономленное время будет больше чем время второго запроса, такого эффекта можно добиться например указав id родителя (не обязательного прямого) в контексте.

Второй пример покажет как лучше всего получить всех прямых потомков.

Не используйте звездочку - это не оправдано в 99.9% случаев (а в этом примере * возвращает еще и затесавшийся случайно элемент link) и не стоит без особой надобности использовать метод children - он тормозит.

В третьем примере я протестирую получение первого прямого потомка.

Не могу найти разумного объяснения почему так тормозит find, но наверное на это есть какие-то причины. А еще интересна разница в использовании eq(0) как селектора и как метода - дольше в полтора раза.

Думаю стоит отвлечся от потомков и протестировать атрибуты. Вытащим input у которых type=radio

Похоже фильтром тоже не стоит злоупотреблять, а псевдо-селекторы придуманы не только для удобства в написании

Ну и конечно надо доколупаться до классов а то было бы не честно

Магия...

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

document.createElement("div");

но сначала нужно убедиться что мы хотим создать именно пустой див

// вызываем jQuery с селектором (а точнее с фрагментом html кода), без контекста
$("<div/>");

дальше идет общая часть для обоих примеров, мы получаем наш текст в переменную string и пытаемся определить что же получили

// проверяем что мы получили html а не селектор
var html = /^[^<]*(<(.|\s)+&gt)[^>]*$|^#([\w-]+)$/.exec(string)
if(html && (html[1] || !context)){
	// это для красоты
	html = html[1];
	// проверяем что наш html просто один тэг
	var tag = /^<(\w+)\s*\/?>$/.exec(html);
	if(tag[0])
		// создаем и возвращаем новый элемент
		return document.createElement(tag[0]);
}

Было бы крайне интересно, если бы можно было передавать еще и контекст в котором нужно создать элемент, тогда можно было бы не писать .appendTo(), но к сожалению это слишком сложно и накладывает кучу ограничений.

Второй пример - сложный, нам не просто надо создать див но надо добавить к нему свойство style и текст

// вызываем jQuery
$("<div style='position:absolute;'>text</div>");

Вторая проверка из прошлого фрагмента кода не пройдена и мы должны уточнить, что же надо создать, попутно создаем вспомогательный див который будет служить нам оберткой

var div = context.createElement("div");

Приводим html к виду xhtml, это значит что если бы у нас была строка

<div style='position:absolute;'/>

то она превратилась бы в

<div style='position:absolute;'></div>

это не относиться к перечисленым тэгам

html = html.replace(/(<(\w+)[^>]*?)\/>/g, function(all, front, tag){
	return tag.match(/^(abbr|br|col|img|input|link|meta|param|hr|area|embed)$/i) ?
		all :
		front + "></" + tag + ">";
});

Затем нужно проверить целостность html'a если мы пытаемся создать элементы которые изначально должны быть вложены в другие, то их следует сначала вложить а потом создать.

var wrap =
	!tags.indexOf("<opt") &&
	[ 1, "<select multiple='multiple'>", "</select>" ] ||


	!tags.indexOf("<leg") &&
	[ 1, "<fieldset>", "</fieldset>" ] ||


	tags.match(/^<(thead|tbody|tfoot|colg|cap)/) &&
	[ 1, "<table>", "</table>" ] ||


	!tags.indexOf("<tr") &&
	[ 2, "<table><tbody>", "</tbody></table>" ] ||


	(!tags.indexOf("<td") || !tags.indexOf("<th")) &&
	[ 3, "<table><tbody><tr>", "</tr></tbody></table>" ] ||


	!tags.indexOf("<col") &&
	[ 2, "<table><tbody></tbody><colgroup>", "</colgroup></table>" ] ||


	// IE не может сериализировать <link> и <script> тэги нормально
	!jQuery.support.htmlSerialize &&
	[ 1, "div<div>", "</div>" ] ||


	[ 0, "", "" ];


div.innerHTML = wrap[1] + elem + wrap[2];

Ну и естественно обертки нам не нужны, мы их отбрасываем

while ( wrap[0]-- )
	div = div.lastChild;

Если у нас было несколько элементов верхнего уровня

<div>text1</div><div>text2</div>

мы бы это все еще разбили в массив, но так как мы этого не знаем и для однородности отдачи мы все равно это делаем

array = Array.prototype.push.apply([], div.lastChild);

Статья изначально предполагалась для объяснения, почему для манипуляций с единичными элементами DOM лучше создавать пустые элементы, а потом методами jQuery добавлять им свойства.

$("<div/>").text("text")
// лучше чем ?
$("<div>text</div>")

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

var start = new Date();
for(var i=0;i<1000;i++)
	$("<div/>").text("text")
var stop = new Date();
alert(stop-start) // 280


var start = new Date();
for(var i=0;i<1000;i++)
	$("<div>text</div>")
var stop = new Date();
alert(stop-start) // 125

Я очень сильно удивился и посмотрел код метода .text() он попутно успевает вызвать метод .empty(), который очень широким жестом удаляет всех потомков текущей ноды. Теория начала с треском проваливаться, но не все методы используют .empty() и я составил табличку, какой метод, сколько времени выполняеться и картина снова стала меня радовать.

Хочу обратить ваше внимание на то что .css() это частный случай для .attr() поэтому работает чуть дольше, но лучше отображает суть происходящего.

Эксперимент доказал, что если требуеться создавать пустой элемент (по большей части это касаеться дивов), то всетаки лучше параметры передавать потом в методах. Это экономит до 50% времени.

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

• Полностью убрано определение браузеров, потому что оно не просто бесполезно а по большому счету мешает и сбивает с толку в случаи с Chrome которого jQuery определяет как Safari , а на самом деле он ведет себя как FireFox . Теперь все везде работает за счет хаков CSS и сглаживания jQuery .
• Сделал давно прошеную фишку, чтобы можно было передавать не только видимое значение (text) но и реальное значение (value). Это работает не только с option, но также с объектами и массивами. Для объекта будет возвращаться ключ, а для массива будет возвращаться порядковый номер начиная с нуля.
• Для того чтобы передача истинного значения выглядела аккуратно пришлось еще добавить режим select-only который не даст пользователю написать свой вариант в autocomplete, но как по мне это не правильно, потому что так все возвращается обратно к функциональности select-box'a.
• По скольку до объекта autocomplete напрямую кроме как из событий добраться нельзя я сделал событие onSetup в котором можно произвести произвольные манипуляции с autocomplete после того как он будет создан. Это позволит управлять элементами назначая им новые обработчики или стили.
• Еще убран хак для Safari так как у меня на винде в найтбилдах он больше не появляется, если он не исчез - пишите и я верну.

В остальных местах еще немного порефакторил. Но это влияет только на производительность. Где-то в глубине рефакторинга решил использовать метод live для всех элементов выпадающего списка, но потом понял что для этого придется отказаться от поддержки jQuery версии 1.2.6, а мне этого не хотелось и подумав еще я сумел сделать код еще проще.

<style>
.myClass{
	color:red;
}
</style>
<select name="myName">
	<option value="101">101</option>
	<option value="102">102</option>
	<option value="103">103</option>
	<option value="104">104</option>
	<option value="105">105</option>
	<option value="106" class="myClass">106</option>
	<option value="107" class="myClass">107</option>
	<option value="108" disabled="disabled">108</option>
	<option value="109" disabled="disabled">109</option>
	<option value="110" disabled="disabled" class="myClass">110</option>
</select>

Теперь напишем селектор который выберет все элементы которые нам видны, которые имеют класс myClass и которые неактивны.

jQuery().ready(function($){
	// выбираем все option
	var o = $("select[name=myName] option");


	// фильтруем
	o.filter(":visible.myClass:disabled");
 });

Работает, но это не оптимальный селектор, даже если он занимает минимум символов при написании, он работает медленно. Надо понимать как это все работает и какая операция быстрее. Итак попробуем разобрать: если бы все было прекрасно и браузер поддерживал функцию document.querySelectorAll, jQuery бы передал ей селектор, но у нас не та ситуация, я специально создал такие условия чтобы querySelectorAll ничего не ускорил, ну или мы используем какой-то старый браузер который не поддерживает этот метод. Итак у нас три части селектора :visible + .myClass + :disabled , (и хотя querySelectorAll понимает второй селектор, jQuery все равно придется обрабатывать первый и третий) примерный код выглядел бы так, только намного сложнее.

// Этот код работает идентично тому как работает jQuery


// выбираем все option без jQuery
var o = document.querySelectorAll("select[name=myName] option"),
tmp1 = [], tmp2 = [], result = [];




function isVisible(obj){
	if (obj == document) 
		return true;
	if(!obj)
		return false;
	if(obj.style.display !== "none" && obj.style.visibility !== "hidden")
		return isVisible(obj.parentNode);
}


// фильтруем
for (var i=0; i<o.length; i++){
	if(isVisible(o[i]))
		tmp1.push(o[i]);
} // 10


for (var i=0; i<tmp1.length; i++){
	var cls = tmp1[i].className.split('/\s+/')
	for (var c in cls)
		if (cls[c] == "myClass")
			tmp2.push(tmp1[i]);
} // 3


for (var i=0; i<tmp2.length; i++){
	if(tmp2[i].getAttribute("disabled"))
		result.push(tmp2[i]);
} // 1


alert(result.length); // 1

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

Итак, считаем:

• первый цикл обойдет все 10 элементов и трудазатраты у него возрастают пропорционально величине DOM дерева (дадим ему модификатор 3)
• второй менее трудозатратен и его величина пропорциональна количеству классов у элемента (модификатор 2)
• и наконец третий цикл совсем простой с минимальным количеством трудозатрат (модификатор 1).

Отсюда вывод, что в примере селекторы лучше всего поменять местами в противоположном порядке - :disabled.myClass:visible.

Конечно пример про :visible натянут тут они все видимы но в реальной ситуации когда выбираются все абзацы текста, все может быть по другому.

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

21.02 UPD: Несколько часов назад вышла jquery-1.3.2.js . В release note сказано что отремонтированы селекторы :visible/:hidden и действительно сейчас они полностью переписаны и не зависят от величины дом дерева.

vae element = document.getElementById("id")
if(!element.offsetWidth && !elem.offsetHeight)
	// hidden
else
	// visible

А это значит про предыдущие расчеты нужно немного подкорректировать и теперь самым 'тяжелым' является селектор класса.

Приведу пример. Мы ищем города начинающиеся на 'К' и получаем от сервера ответ ['кардуба','кардижопа','казупий','кипир'] :) При вводе второй буквы мы уже не обращаемся к серверу, а фильтруем то, что получили прошлый раз, например вторая буква 'А' тогда 'КА' = ['кардуба','кардижопа','казупий']. При вводе третьей буквы все повторяется 'КАР' = ['кардуба','кардижопа'].

Я вижу два выхода из этой ситуации.

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

Второй способ полон геморроя и собственно его я и буду дальше описывать. Для его реализации понадобиться намного больше память, но намного меньше времени, я не могу сказать, что лучше память или время, но могу сказать, что второй способ хотя бы напряг мои мозги. Так вод вам понадобиться: вазелин офисный, пол литра, руки прямые, две штуки и терпение, много терпения, хотя нет, руки, пожалуй, должны сгибаться в локтях....

Итак что собственно делаем. Вводим первую букву 'К', получаем от сервера ответ и сохраняем в переменной cache в таком виде.

cache =  {
	'К':['кардуба','кардижопа','казупий','кипир']
};

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

cache = {
	'К':['кардуба','кардижопа','казупий','кипир'],
	'КА':['кардуба','кардижопа','казупий']
};

Еще раз та же процедура вводим 'Р', строка 'КАР', берем ключи объекта, разворачиваем в обратном порядке (чтобы сначала шли самые длинные), и ищем их вхождение в строку, если нашлось то снова фильтруем и сохраняем.

cache = {
	'К':['кардуба','кардижопа','казупий','кипир'], 
	'КА':['кардуба','кардижопа','казупий'], 
	'КАР':['кардуба','кардижопа']
};

Как видите одни и те же города находятся в массиве много раз, это есть не очень экономно с точки зрения памяти но зато к ним очень быстро можно получить доступ. Реализация этого метода тоже весьма муторная и я был бы не против сильно её заоптимайзить но вот что-то никак...

var cache = {'':['кардуба','кардижопа','казупий','кипир','другой город','еще село']},
	mask = ['к','ка','кар'];


function check(mask){
	// пытаемся быстро выйти
	if (cache[mask])
		return cache[mask]; 


	// инициализируем переменные
	var map = [], array = [];


	// получаем массив ключей
	for(var item in cache)
		array.push(item);
	// разворачиваем самыми длинными вначало
	array = array.reverse();


	// ищем...
	for(var item in array)
		// если вхождение ключа в строку имеет нулевую позицию
		if(!mask.indexOf(array[item])){
			// фильтруем
			for(var word in cache[array[item]])
				// если вхождение строки в элемент иммеет нулевую позицию
				if (!cache[array[item]][word].indexOf(mask))
					// сохраняем
					map.push(cache[array[item]][word]);
			break;
		}
	alert(map);
	cache[mask] = map
}


for (m in mask)
	check(mask[m]);

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

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

Вот я и сделал наконец поиск по сайту, вообще еще много чего надо сделать, а то я даже страницы добавляю через MySQL. Сейчас поиск ищет по заголовку, описанию и собственно телу страницы, самое приятное в нем то, что в нем есть ранжирование результатов. Если кому-то интересно как такое сделать то читайте дальше.

MATCH() ... AGAINST() первое, что приходит в голову, когда говорят о поиске с релевантностью, забудьте об этом бреде!!! Во-первых, это накладывает очень два ограничений: первое и главное - надо делать полнотекстовые индексы, без них никак, второе - индексы можно сделать только на таблицах MyISAM. Во вторых это просто глючно, потому что при поиске небольших фраз по большой базе их релевантность близка к абсолютному нулю, или же если слово присутствует в более 50% строк, то оно не учитывается.

SELECT 
MATCH('Content') AGAINST ('keyword1 keyword2') as Relevance 
FROM table 
WHERE MATCH ('Content') AGAINST('+keyword1 +keyword2' IN BOOLEAN MODE) 
HAVING Relevance > 0.2 
ORDER BY Relevance DESC

Это так сказать классический способ поиска, взятый с сайта самого мускула, но ИМХО это большая ошибка, тут первый MATCH выдает релевантность, а второй который IN BOOLEAN MODE используется для поиска обоих слов сразу в одной строке, если есть только одно то он выдаст 0. Если слов больше двух то это начинает давать сильную погрешность, выдавая только те ряды, где есть все слова фразы. Более того, куча MATCH сильно тормозит запрос.

Поэтому лучше ввести весовые коэффициенты в запрос. Коэффициенты вы раздаете сами, поэтому их общее число всегда может быть в пределах 100 и к нему можно смело добавлять знак %. Итак у нас есть три колонки title, description и text. Если в каждом из трех полей есть искомое словосочетание то релевантность 100%, при этом каждое поле имеет свой вес: заголовок - самый большой(40%), потом описание(20%) а потом уже текст(10%). Я считаю, что полное словосочетание это 70% релевантности и если есть все слова из него, то это еще 30%. немного запутал, сейчас объясню. Есть словосочетание "мама мыла раму", если оно дословно есть во всех полях то это 70%, а если в каждом из них есть "раму мыла мама", то это только 30%. В результате мы получаем либо 100% (70% все вместе и 30% каждое по отдельности) совпадение со строкой либо только 30% (каждое по отдельности) совпадение, ну это лично мое мнение.

Итак алгоритм будет выгладить следующим образом:

$text = "мама мыла раму";
$query = "SELECT *, 
IF (title like '%".$text."%', 40, 0) + IF (title LIKE '%".str_replace(" ", "%', 5.71, 0) + IF (title LIKE '%", $text)."%', 5.71, 0) + 
IF (description like '%".$text."%', 20, 0) + IF (description LIKE '%".str_replace(" ", "%', 2.86, 0) + IF (description LIKE '%", $text)."%', 2.86, 0) +
IF (text like '%".$text."%', 10, 0) + IF (text LIKE '%".str_replace(" ", "%', 1.43, 0) + IF (text LIKE '%", $text)."%', 1.43, 0) AS rel
FROM pages 
WHERE 
(title LIKE '%".str_replace(" ", "%' OR title LIKE '%", $text)."%') OR
(description LIKE '%".str_replace(" ", "%' OR description LIKE '%", $text)."%') OR
(text LIKE '%".str_replace(" ", "%' OR text LIKE '%", $text)."%') 
ORDER BY rel DESC";

Если подставить значения будет выглядеть менее запутано но все равно непонятно

SELECT *, 
IF (title LIKE '%мама мыла раму%', 40, 0) + IF (title LIKE '%мама%', 5.71, 0) + IF (title LIKE '%мыла%', 5.71, 0) + IF (title LIKE '%раму%', 5.71, 0)  + 
IF (description LIKE '%мама мыла раму%', 20, 0) + IF (description LIKE '%мама%', 2.86, 0) + IF (description LIKE '%мыла%', 2.86, 0) + IF (description LIKE '%раму%', 2.86, 0)  + 
IF (text LIKE '%мама мыла раму%', 10, 0) + IF (text LIKE '%мама%', 1.43, 0) + IF (text LIKE '%мыла%', 1.43, 0) + IF (text LIKE '%раму%', 1.43, 0) AS rel
FROM pages 
WHERE 
(title LIKE '%мама%' OR title LIKE '%мыла%' OR title LIKE '%раму%') OR
(description LIKE '%мама%' OR description LIKE '%мыла%' OR description LIKE '%раму%') OR
(text LIKE '%мама%' OR text LIKE '%мыла%' OR text LIKE '%раму%')
ORDER BY rel DESC

Вот такой немаленький запросик получился))) Теперь попробуем разобрать что значат все эти непонятные коэффициенты 5.71, 2.86 и 1.43. Для этого я нарисую маленькую табличку.

Сумма первого столбика получается как раз 70%, сумма всех остальных ячеек 30% в результате искомые 100% релевантности. Сумма каждого следующего столбика 10%. А сумма каждой ячейки высчитывается по формуле (вес поля) * (общее число процентов 30) / (общее число коэффициентов 7) / (количество слов), если подставить поле title то выйдет 4*30/7/3 = 5.71. В общем, я думаю, поняли, кто не понял, возьмите калькулятор!

В том что такой запрос отрабатывает весьма шустро вы можете перейдя на страницу поиска, там выводиться время потраченное на запрос.

Кстати в моем поиске еще наложена логика отключения полей, если отключено одно поле то коэффициенты становятся 3 и 4 , а если отключено два поля то оставшееся имеет коэффициент 7. И еще не забудьте удалить пробелы в начале и конце строки, а также двойные пробелы в середине. Все!