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

Question

[Павел Осипов]

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

Заранее благодарен

Answer 1

[sasha]

мистер, вы упороты. любая манипуляция с DOM сравнима с операциями Input\Output , что, как бы намекает, не переборщи. а 250 зависимостей это как раз тот случай когда переборщил. джквери парсит строку запроса потом просто делает запросы getElementBy.... , тоесть тут не зарыто клада оптимизации. тормозит - убери без чего мож обойтись. не можешь обойтись-смирись.

Comments

[Павел Осипов]

Ну да, дело ясное. Пробую всё кешировать в массивы нативные, чтобы с DOM по минимуму работать. В т.з. изначально было up to 5 toggled blocks :D

[sasha]

@Pavel_Osipov 5 это не 250. навскидку до 50 еще както жить можно. но вот 250... я даже ситуации такой не могу себе представить где оно может пригодиться...

[Павел Осипов]

Да. Аппетит у админов приходит во время еды. Хорошо хоть 250, это уже реально максимум. Ну да будем думать, в Хроме вон и 250 за пару секунд отрабатывают.

Answer 2

[Константин Китманов]

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

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

Comments

[Павел Осипов]

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

Answer 3

[Сергей Мельников]

надо сохранять ссылки на нужные елементы сразу в переменные, а потом ими пользоваться (что бы небыло постоянной переборки DOM)
ссылку дайте на пример

Comments

[Павел Осипов]

Ну да, кешировать всё в нативных массивах, так видимо и буду делать.
Пример так просто и не вытащить отдельно. Вот тут, как всё ворочается при десятке переключаемых объектов:
https://tjenestetorget.no/boliglaan/
Код реализующий это:
https://tjenestetorget.no/include/themes/default/j...
- блок //******************Showhide functionality
строки 1552 - 2029

[trushka]

не обязательно на сами эдементы ссылки делать, можно на наборы элементов сразу, так сказать. То есть типа
var $el = $('selector')
и там уже будут готовые ссылки на объекты DOM, а не будет их при каждом вызове искать

[Павел Осипов]

Ну в принципе я и имел в виду, что $('selector') в массив загонять

Answer 4

[Vitaly Sivkov]

Прогоны через профайлер делали?

Comments

[Павел Осипов]

Ответил ниже, промазал по комменту

Answer 5

[Павел Осипов]

Конечно. В частности по этому и возник вопрос о специфике 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)

Comments

[Vitaly Sivkov]

У вас там очень много каскадных событий. Также в пиковых нагрузках присутствует обработка анимации, попробуйте вместо fadeIn/fadeOut простой hide/show.

[Павел Осипов]

Да, спасибо, так и сделал уже, красоту убрал, вместо
trgt_holder.fadeTo( "fast" , 0, function() {
просто
trgt_holder.css( 'display', 'none' );
теперь.
В принципе примерно на 20% быстрее стало.

Без каскадных событий никуда, там довольно сложные зависимости могут быть :)

[Владимир Т.]

Анимацию лучше перекинуть на CSS. Так и красиво будет и тормозить не будет.

[Павел Осипов]

Спасибо! Да, знаю, что CSS бывает аппаратно ускоренный. Но сейчас там из JS мы только и с .css( 'display','none') свойством работаю, считаете, что замена его на что-то типа .addClass( 'no_display') может дать прирост производительности?

Вообще, на данный момент я стал использовать requestAnimationFrame и всё стало заметно шустрее. На хроме так вообще летает :)

Answer 6

[GM2mars]

Посмотрите в сторону AngularJS, манипуляции с DOM он делает шустрее, то что вам нужно, можно без проблем на нем реализовать. Меньше кода и больше скорость работы.
Вот чтоб вам не искать angular.ru

Comments

[Павел Осипов]

Спасибо. Я сталкивался с этой штукой. В своё время выбирали между ним и knockout.js. Выбрали второй, так-как задача была небольшая, а есть мнение, что для небольших задач он лучше. Честно говоря, не очень я в восторге от knockout, да и angular много чаще упоминается последнее время на том же хабре.
Так-что спасибо за идею.
Вопрос такой, "шустрее", это на сколько?

[GM2mars]

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

[Павел Осипов]

Благодарю за Ваше мнение. Попробую перевести на ангулар, посмотрим :)

[Владимир Т.]

Ангуляр тоже проседает под большими списками

[Павел Осипов]

Вы правы, прироста скорости в моей задаче с ним не получилось. Ну да, как я уже писал, у меня всё в производительность JQWidgets упёрлось, а их ковырять сейчас не резон

Answer 7

[Борис Пеньковский]

Вы бы показали отрывки кода

Comments

[Павел Осипов]

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

Вообще, я так начал подозревать, что скорее всего всё дело тормозит jQWidgets, а не сам showhide функционал .

Answer 8

[Павел Осипов]

В итоге. Больше всего кушает производительность jQWidgets. При работе с нативными элементами, даже самый большой вариант с 250-ю элементами на старом IE8 обрабатывается не больше секунды.
Поэтому и оптимизации нашего кода выигрыша так мало давали, что не в нём затык. Ну и смысла на ангулар переписывать тоже нет в данном случае.
Хотя конечно Native DOM is fast!