Comments 32
а че, в jquery нет кэширования? и какой прирост скорости?
Ну если есть, покажите пожалуйста, я не смог найти.
Прирост скорости имеется если какой-то конкретный селектор неоднократно вызывается. При единичном использовании ясно что не будет прироста.
Прирост скорости имеется если какой-то конкретный селектор неоднократно вызывается. При единичном использовании ясно что не будет прироста.
Ну если есть, покажите пожалуйста, я не смог найти.
Прирост скорости имеется если какой-то конкретный селектор неоднократно вызывается. При единичном использовании ясно что не будет прироста.
Прирост скорости имеется если какой-то конкретный селектор неоднократно вызывается. При единичном использовании ясно что не будет прироста.
а как кеш очищать, если DOM поменяется и кеш станет неактульным?
Спасибо, поапдейтил.
$.cache.get('...');
$.cache.clear();
$.cache.get('...');
$.cache.clear();
Может стоит еще чуть-чуть усовершенствовать, чтобы работал $.cache.clear(selector). Иначе из-за одного некешируемого селектора(блока на странице) будет вычищаться содержимое всего кеша и надобность присутствия такого плагина уже сомнительна.
Может тогда сделать и какое обновление кэша по тем же селекторам но по новому DOM… к примеру $.cache.update(); и/или $.cache.update('селектор');
Прироста может и не быть, в зависимости от браузера. Совершенно :)
Почему прироста может не быть? Из-за работы с внутренней реализации [] браузером? Т.е. поиск по селектору может сработать быстрее поиска элемента по ключу?
если в браузере уже реализовано кэширование селекторов, то возможно будет даже медленней
Не не. Они сами его кешируют, если DOM не изменяется.
В Опере это так было. Не помню, кажется читал в техногрете лебедева.
А вообще, действительно, стоит сохранять часто используемый элемент как локальную переменную — так еще быстрее будет.
В Опере это так было. Не помню, кажется читал в техногрете лебедева.
А вообще, действительно, стоит сохранять часто используемый элемент как локальную переменную — так еще быстрее будет.
Если такое кэширование не работает прозрачно для пользователя (в смысле что нужно принудительно вызывать $.cache.get(...), а не просто $(...)), то почему просто не сохранять результат работы селектора в переменную?
var elems = $('div.some-class'); elems.each(...); // do something elems.each(...); // do something else
Вот здесь — habrahabr.ru/blogs/javascript/63119/ описана изначальная задача в процессе обсуждения которой появился этот плагин.
А приведенным выше примером эта проблема не решается? И у меня есть большие подозрения, что в приведенной ссылке узким местом является не поиск элементов по СSS-запросу (у вас внутри $('#'+rootId) должны быть сотни элементов, чтобы вызвать проблемы с производительностью). Если покажете рабочий пример, можем дружно посмотреть и найти проблемное место с помощью профайлера.
Передаваемых rootId несколько разных. Приходится для каждого кэшировать работу $(...) что и было сделано с помощью замыканий. После этого проблемы со скоростью исчезли.
Проблему можно было решить изменением верстки и оптимизацией самих выборок по селекторам.
Хотелось найти именно решение без изменения окружающей архитектуры.
Рабочий пример показать к сожалению не могу, проект пока в разработке и закрыт. Аналог — скандинавский аукцион gagen.ru. Узкое место — функция обновления лотов настранице — пересчет времени, вывод лидеров, новых цен.
Проблему можно было решить изменением верстки и оптимизацией самих выборок по селекторам.
Хотелось найти именно решение без изменения окружающей архитектуры.
Рабочий пример показать к сожалению не могу, проект пока в разработке и закрыт. Аналог — скандинавский аукцион gagen.ru. Узкое место — функция обновления лотов настранице — пересчет времени, вывод лидеров, новых цен.
Если надо сделать как на gagen.ru, то я бы сделал так: после загрузки документа один пробежался по нужным контейнерам с id продукта, и у каждого закэшировал указатели на нужные элементы (цена, время и т.д.) с помощью $(...).data(). А при обновлении данных обращался к ним через $(rootId).data('price').doSomething(). И не надо городить огород из тяжелых замыканий или плагинов, организующих псевдо-кэширование.
в функции get код красиво и правильно сокращен *respect*
yass лучший в этом )
Предложенная архитектура кривовата: если мы вверху вдруг закомментируем/уберем первоначальное обращение (или изменим порядок), то все перестанет работать.
Вариант ничем не лучше обычного сохранения в локальной переменной
var $mysel = $('selector… ');
$mysel.show();
$mysel…
Вариант ничем не лучше обычного сохранения в локальной переменной
var $mysel = $('selector… ');
$mysel.show();
$mysel…
Какое «первоначальное» обращение хочется закоментировать? То, которое //Before — это пример кода до использования cache.plugin
// After — как адаптируется код для применения плагина
// After — как адаптируется код для применения плагина
Обычного сохранения в переменную вариант лучше тем, что позволяет не запоминать в какую там переменную что было сохранено. Проще адаптировать код.
Я думаю надо выбрать другой подход к увеличению произоводтельности на клиентской стороне,
Почему? Потому что если так пойти, то в конце получим классный кэшер но с много коде те файл с большим размером
пс мне так кажется
Почему? Потому что если так пойти, то в конце получим классный кэшер но с много коде те файл с большим размером
пс мне так кажется
Sign up to leave a comment.
Кэширование селекторов для jQuery. Плагин