Кэширование селекторов для jQuery. Плагин

[@evilbloodydemon]

а че, в jquery нет кэширования? и какой прирост скорости?

[@Olegas]

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

[@nicothin]

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

var tmp = $('#some .css .selector');
$(tmp).что().угодно();
[...]
$(tmp).как().угодно();

[@Olegas]

Уже многократно отвечал в комментариях.

[@Olegas]

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

[@smilegs]

а как кеш очищать, если DOM поменяется и кеш станет неактульным?

[@Olegas]

Спасибо, поапдейтил.
$.cache.get('...');
$.cache.clear();

[@ferrari]

Может стоит еще чуть-чуть усовершенствовать, чтобы работал $.cache.clear(selector). Иначе из-за одного некешируемого селектора(блока на странице) будет вычищаться содержимое всего кеша и надобность присутствия такого плагина уже сомнительна.

[@Olegas]

Кармы нет чтобы проапдейтить пост…
в общем будет примерно так:

clear: function(selector) {
selector == null? selectorCache = []: selectorCache[selector] = null;
}

[@AGITA]

Может тогда сделать и какое обновление кэша по тем же селекторам но по новому DOM… к примеру $.cache.update(); и/или $.cache.update('селектор');

[@varyen]

Прироста может и не быть, в зависимости от браузера. Совершенно :)

[@Olegas]

Почему прироста может не быть? Из-за работы с внутренней реализации [] браузером? Т.е. поиск по селектору может сработать быстрее поиска элемента по ключу?

[@dab512]

если в браузере уже реализовано кэширование селекторов, то возможно будет даже медленней

[@varyen]

Не не. Они сами его кешируют, если DOM не изменяется.
В Опере это так было. Не помню, кажется читал в техногрете лебедева.

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

[@Olegas]

Именно в моем случае было недостаточно сохранить как локальную переменную. В посте по ссылке можно почитать почему. Там это решалось с помощью замыканий.

По крайней мере в FF3, IE6+, Chrome оба метода (замыкания и $.cache.get) дали на глаз заметное преимущество.

[@chikuyonok]

Если такое кэширование не работает прозрачно для пользователя (в смысле что нужно принудительно вызывать $.cache.get(...), а не просто $(...)), то почему просто не сохранять результат работы селектора в переменную?

var elems = $('div.some-class');

elems.each(...); // do something

elems.each(...); // do something else

[@Olegas]

Вот здесь — habrahabr.ru/blogs/javascript/63119/ описана изначальная задача в процессе обсуждения которой появился этот плагин.

[@chikuyonok]

А приведенным выше примером эта проблема не решается? И у меня есть большие подозрения, что в приведенной ссылке узким местом является не поиск элементов по СSS-запросу (у вас внутри $('#'+rootId) должны быть сотни элементов, чтобы вызвать проблемы с производительностью). Если покажете рабочий пример, можем дружно посмотреть и найти проблемное место с помощью профайлера.

[@Olegas]

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

Проблему можно было решить изменением верстки и оптимизацией самих выборок по селекторам.

Хотелось найти именно решение без изменения окружающей архитектуры.

Рабочий пример показать к сожалению не могу, проект пока в разработке и закрыт. Аналог — скандинавский аукцион gagen.ru. Узкое место — функция обновления лотов настранице — пересчет времени, вывод лидеров, новых цен.

[@chikuyonok]

Если надо сделать как на gagen.ru, то я бы сделал так: после загрузки документа один пробежался по нужным контейнерам с id продукта, и у каждого закэшировал указатели на нужные элементы (цена, время и т.д.) с помощью $(...).data(). А при обновлении данных обращался к ним через $(rootId).data('price').doSomething(). И не надо городить огород из тяжелых замыканий или плагинов, организующих псевдо-кэширование.

[@ferrari]

в функции get код красиво и правильно сокращен *respect*

[@BACRHR]

если бы кода было бы побольше, то не думаю что
return selectorCache[selector] || (selectorCache[selector] = $(selector));
был бы красивым и удобным. Потом же сам будешь искать, а где же оно присваивается :)

[@DriverX]

yass лучший в этом )

[@0lympian]

Предложенная архитектура кривовата: если мы вверху вдруг закомментируем/уберем первоначальное обращение (или изменим порядок), то все перестанет работать.

Вариант ничем не лучше обычного сохранения в локальной переменной
var $mysel = $('selector… ');
$mysel.show();
$mysel…

[@Olegas]

Какое «первоначальное» обращение хочется закоментировать? То, которое //Before — это пример кода до использования cache.plugin

// After — как адаптируется код для применения плагина

[@0lympian]

Ну да. Вот был у нас и //Before и //After. Разнесенные в коде. Потом бац и //Before вдруг по каким-либо причинам перестал получать управление. Что тогда? //After тоже перестанет работать?

[@Olegas]

Нет, естественно не перестанет. Все будет работать верно. Почитайте код плагина.

[@Olegas]

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

[@0lympian]

Ну можно и в одну запоминать

[@0lympian]

var $cache = [];
$cache['.sel1'] = $('.sel1);
$cache['.sel1']…

В чем смысл? :)

[@Olegas]

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

[@jandosul]

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