У меня есть сильно оптимизированное приложение JavaScript, высокоинтегрированный графический редактор. Теперь я начал профилировать его (используя инструменты Chrome dev) с огромным количеством данных (тысячи фигур на графике), и я столкнулся с ранее необычным узким местом производительности Hit Test.
| Self Time | Total Time | Activity |
|-----------------|-----------------|---------------------|
| 3579 ms (67.5%) | 3579 ms (67.5%) | Rendering |
| 3455 ms (65.2%) | 3455 ms (65.2%) | Hit Test | <- this one
| 78 ms (1.5%) | 78 ms (1.5%) | Update Layer Tree |
| 40 ms (0.8%) | 40 ms (0.8%) | Recalculate Style |
| 1343 ms (25.3%) | 1343 ms (25.3%) | Scripting |
| 378 ms (7.1%) | 378 ms (7.1%) | Painting |
Это занимает 65% всего (!), Оставаясь узким местом монстра в моей кодовой базе. Я знаю, что это процесс отслеживания объекта под указателем, и у меня есть свои бесполезные идеи о том, как это можно оптимизировать (использовать меньшее количество элементов, использовать меньше событий мыши и т.д.).
Контекст: приведенный выше профиль производительности показывает функцию "панорамирования экрана" в моем приложении, где содержимое экрана можно перемещать, перетаскивая пустую область. Это приводит к множеству объектов, перемещаемых вокруг, оптимизированных путем перемещения их контейнера, а не каждого объекта отдельно. Я сделал демо.
Прежде чем перейти к этому, я хотел найти общие принципы оптимизации тестирования ударов (те хорошие статьи о блоге "Нет sh * t, Sherlock"), а также, если существуют какие-либо трюки для повышения производительности с этой целью (например, используя translate3d
чтобы включить обработку GPU).
Я пробовал запросы, такие как js optimize hit test, но результаты полны статей графического программирования и примеров ручной реализации - это как если бы сообщество JS даже не слышало об этом раньше! Даже руководству хром devtools не хватает этой области.
- Изменение: есть этот вопрос, но это не очень помогает: что такое временная шкала Chrome Dev Tools "Хит-тест"?
Итак, вот я, с гордостью сделанный с моими исследованиями, спрашивая: как мне получить оптимизацию тестов на местное тестирование в JavaScript?
Я подготовил демоверсию, которая демонстрирует узкое место производительности, хотя это не совсем то же самое, что и мое фактическое приложение, и цифры, очевидно, будут меняться и на устройстве. Чтобы увидеть узкое место:
- Перейдите на вкладку "Временная шкала" в Chrome (или эквиваленте вашего браузера)
- Начните запись, затем развернитесь в демо, как сумасшедший
- Остановите запись и проверьте результаты
Резюме всех значительных оптимизаций, которые я уже сделал в этой области:
- перемещение одного контейнера на экране вместо перемещения по тысячам элементов по отдельности
- с помощью
transform: translate3d
для перемещения контейнера - v-синхронизация движения мыши с частотой обновления экрана
- удаление всех возможных ненужных элементов "обертки" и "фиксатора"
- использование
pointer-events: none
на фигурах - нет эффекта
Дополнительные замечания:
- узкое место существует как с ускорением GPU, так и без него
- тестирование было выполнено только в Chrome, последние
- DOM создается с использованием ReactJS, но та же проблема наблюдается без него, как видно из связанной демонстрации