dirty-on-steroids
dirty-on-steroids copied to clipboard
crimaniak
Производительность модулей
Инбоксах с большим количеством комментариев производительность сервиспака оставляет желать лучшего. Пример (более 600 комментов, из них более 500 новых):
| runtime | 2779 |
| Навигация по новым | 1405 |
| Dirty tooltip | 316 |
| Пряталки рейтинга | 217 |
| Показывать favicons доменов | 205 |
| Цветовая дифференциация полов | 165 |
| Приглушать удаленные комментарии | 155 |
| Цветной рейтинг | 152 |
| Раскрытие картинок по клику на ссылке | 81 |
| Просмотр видео по клику на ссылке | 45 |
| Выделять ссылки на подсайты в постах | 14 |
| Рестайлинг сайта от dirty tort | 4 |
| Показываться онлайн через d3search | 4 |
| Прятать пользователей инбокса под ссылку | 2 |
| Показывать все комментарии в посте | 2 |
| Показывать внешние ссылки из заголовков постов | 2 |
| Каноничные гертруды | 2 |
| Анонимные авторы постов | 2 |
| config core module | 2 |
| Прятать посты с низким рейтингом | 1 |
| Помечать как прочитанное | 1 |
| Добавлять предпросмотр для комментариев | 1 |
| XD | 1 |
| Широкая главная | 0 |
| Спрятать лишнее | 0 |
| Показывать посты целиком без "развернуть" | 0 |
| Линк на последнюю версию | 0 |
| Добавление видео к комментариям | 0 |
| Бесконечная страница | 0 |
Нужно пробовать оптимизировать производительность, возможно путем перевода селекторов с jquery на xpath.
а xpath быстрее заметно? кстати, стасик делал глушилку эвентов в прошлом сп на время запуска, вроде как помогало немного. тут же эвентов добавляется на всё что ни попадя, DOM правится как угорелый и т.д.
кстати, стасик делал глушилку эвентов в прошлом сп на время запуска
Не понял, как это?
Dobavlajesh vo vse event listeneri tipa
if(supressEvents){ e.preventDefault(); return; }
Po okon4anii zagruzki stavish sepressEvents=false;
Ne znaju pomoshet li ono s novoj architekturoj.
Sorry za translit...
Am 03.12.2012 um 21:25 schrieb crea7or [email protected]:
ÎÅ ÚÎÁÀ, ÓÍÏÔÒÉ supressEvents × ÓÔÁÒÏÍ ÓÐ.
Reply to this email directly or view it on GitHubhttps://github.com/crimaniak/dirty-on-steroids/issues/49#issuecomment-10970011.
А модули в modules.txt у нас упорядочены по тому, насколько быстро они нужны пользователю, или просто по времени добавления?
А модули в modules.txt у нас упорядочены по тому, насколько быстро они нужны пользователю, или просто по времени добавления?
Некоторые по времени добавления. Некоторые упорядочены относительно друг друга, если того требует их workflow, например, hide.posts.by.rating.js и right.navigator.js.
Тогда, например, модули Раскрытие картинок по клику на ссылке 81 Просмотр видео по клику на ссылке 45
можно задвинуть в самый низ - субъективно для пользователя будет быстрее грузиться, а использовать он их сразу вряд ли будет.
Ну, это кроме реальной оптимизации.
можно задвинуть в самый низ - субъективно для пользователя будет быстрее грузиться, а использовать он их сразу вряд ли будет.
Лично у меня ff на время работы скрипта виснет наглухо. Возможно, в других браузерах это не так.
И всётаки это из за эвентов имхо, смотрим на right.navigator там такая логика что на каждый onComment он пересчитывает все массивы постов. При загрузке страницы это получается уже сложность O(n^2). По идее все эти onPost и onComment должны быть вызваны только при динамическом добавлении вещей (я знаю что для инбоксов это не так).
что будем делать?
Просто right.navigator не переделан на новую логику. Процедура countItems() не нужна более, надо просто инкрементировать нужные переменные в onPost и onComment. Надо переделать.
И да, d3.xpath использует нативный поиск и, естественно, быстрее поиска jQuery.
Перед тем, как создать этот issue, я уже пофиксил right navigator, он теперь работает за O(n). Но все равно тормозит на больших постах. (К слову, до этого он работал на порядок медленнее).
По поводу ивентов. onPost и onComment вызываются в цикле для всех начальных постов и комментариев. Цикл внутри модуля по, например, постам, не будет быстрее цикла внутри ядра, вызывающего onPost.
Я думаю, оптимизация должна заключаться в тюнинге медленных модулей (с частичным переводом на xpath) и реализацией события onUpdate (#48), чтобы тяжелые глобальные вещи обновлялись после процессинга всей группы элементов, а не после каждого.
заменил вот это: $j('a[href^="http://"][href*=".d3.ru"]:contains(.d3.ru)', post.info).addClass(this.styleName);
в выделялке подсайтов на тот страшный код что закоммитил сейчас. было ~70мс -> 1мс (хром 23) и ~30мс -> 3мс в (FF 17)
в хроме добавление стилей в head занимает 30мс+, а добавление к элементу (даже многократное) почти ничего не стоит.
Для справки - jQuery для того, чтобы спрятать/показать комментарии:
d3.content.comments[i].container.hide();
d3.content.comments[i].container.show();
лучше не использовать, если комментариев больше сотни.
Прямое применение css работает очень быстро:
d3.content.comments[i].container.css("display", "none");
d3.content.comments[i].container.css("display", "block");
Однако последний вариант ломает кнопки "все комментарии" / "новые". Я не разбирался, как исправить.