Pavel_Osipov
@Pavel_Osipov
Программист, в основном web

Что сделать для ускорения логики реализованной на jQuery?

Ситуация такая. На сайте есть возможность управления видимостью элементов в зависимости от состояния других элементов. Т.е. пометил чекбокс - появился дополнительный блок, убрал с него checked - блок пропал + все элементы в нём очистились.
Пока целевых блоков было 5-10, всё ОК, но админы быстро захотели запихать туда 100-200 и стало заметно тормозить при переключении. Всё там реализовано на довольно сложных селекторах, вызовах closest(), $.each, jQuery.inArray, данные хранятся в data-showhide- атрибутах. Т.е. jQuery используется активно.
Попробовал переписать все $.each на нативные JS циклы, выигрыш 1%-2% плюс код стал менее читабельным, вернули назад. Попробовали минимизировать количество вызовов $ и по максимуму использовать нативные JS объекты, тоже не более 5% выигрыша + усложнение восприятия кода.
Кто подскажет, есть-ли какие неявные моменты, которые в jQuery кушают производительность? Ведь не может цикл перебора максимум тысячи элементов так серьёзно кушать ресурсы.

Заранее благодарен
  • Вопрос задан
  • 3273 просмотра
Пригласить эксперта
Ответы на вопрос 8
madmages
@madmages
Человек прямоходящий
мистер, вы упороты. любая манипуляция с DOM сравнима с операциями Input\Output , что, как бы намекает, не переборщи. а 250 зависимостей это как раз тот случай когда переборщил. джквери парсит строку запроса потом просто делает запросы getElementBy.... , тоесть тут не зарыто клада оптимизации. тормозит - убери без чего мож обойтись. не можешь обойтись-смирись.
Ответ написан
k12th
@k12th
console.log(`You're pulling my leg, right?`);
Ведь не может цикл перебора максимум тысячи элементов так серьёзно кушать ресурсы.
Если речь идет об обращениях к DOM, то может. Оптимизация в этом случае заключается в сокращении количества операций с DOM. Что именно можно сделать в вашем случае за глаза не скажешь.
Ответ написан
mlnkv
@mlnkv
JavaScript Developer
надо сохранять ссылки на нужные елементы сразу в переменные, а потом ими пользоваться (что бы небыло постоянной переборки DOM)
ссылку дайте на пример
Ответ написан
Sivkoff
@Sivkoff
Web Developer
Прогоны через профайлер делали?
Ответ написан
Pavel_Osipov
@Pavel_Osipov Автор вопроса
Программист, в основном web
Конечно. В частности по этому и возник вопрос о специфике jQuery.
anonymous	4122	11.13%	521.408ms	536.344ms	0.13ms	0.02ms	15.852ms	
jquery-1.7.min.js (line 5)
anonymous	1253	9.65%	452.25ms	1200.76ms	0.958ms	0.138ms	10.676ms	
jquery-1.7.min.js (line 5)
anonymous	997	8.35%	391.145ms	730.162ms	0.732ms	0.498ms	8.161ms	
jquery-1.7.min.js (line 5)
anonymous	157	4.89%	229.15ms	683.487ms	4.353ms	0ms	12.773ms	
jqx-all.js (line 8)
anonymous	3126	4.57%	214.035ms	275.931ms	0.088ms	0.009ms	0.478ms	
jquery-1.7.min.js (line 5)
anonymous	4722	3.3%	154.802ms	218.099ms	0.046ms	0.022ms	0.53ms	
jquery-1.7.min.js (line 4)
anonymous	1389	3.25%	152.249ms	393.61ms	0.283ms	0.024ms	49.364ms	
jquery-1.7.min.js (line 4)
anonymous	930	2.62%	122.747ms	126.521ms	0.136ms	0ms	8.943ms	
jquery-1.7.min.js (line 5)
Ответ написан
GM2mars
@GM2mars
Посмотрите в сторону AngularJS, манипуляции с DOM он делает шустрее, то что вам нужно, можно без проблем на нем реализовать. Меньше кода и больше скорость работы.
Вот чтоб вам не искать angular.ru
Ответ написан
Able1991
@Able1991
Пишу на рельсах
Вы бы показали отрывки кода
Ответ написан
Pavel_Osipov
@Pavel_Osipov Автор вопроса
Программист, в основном web
В итоге. Больше всего кушает производительность jQWidgets. При работе с нативными элементами, даже самый большой вариант с 250-ю элементами на старом IE8 обрабатывается не больше секунды.
Поэтому и оптимизации нашего кода выигрыша так мало давали, что не в нём затык. Ну и смысла на ангулар переписывать тоже нет в данном случае.
Хотя конечно Native DOM is fast!
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы