Как отладить странность производительности в Chrome?

Question

Я создаю приложение JavaScript и в основном тестирую его в Chrome. Приложение включает в себя значительную долю манипуляций и построения DOM.

Моя проблема: при определенных обстоятельствах приложение внезапно становится в несколько раз медленнее. Это выглядит как логическое и предсказуемое значение: каждый раз, когда я выполняю определенное действие, оно замедляется и будет оставаться таковым до тех пор, пока я не выполню одно из конкретных действий, после которого производительность вернется к норме.

Что меня удивляет, так это то, что я ничего не вижу в коде, который мог бы предложить причину этого. Извините, код слишком сложный, чтобы привести пример, особенно учитывая, что я не могу выделить причины этого.

Одним из действий, которое ускоряет его резервное копирование, является щелчок в документе; даже пустые области, даже если я не регистрирую соответствующие обработчики mousedown / click, каким-то образом щелчок волшебным образом восстанавливает здоровье приложения. Напротив, программная очистка фокуса с помощью $(document).find('*').blur() и фокусировка несфокусированного элемента с помощью $('#some_button').focus() не помогают.

Я также тестировал на Firefox и Opera. У меня довольно серьезные проблемы с производительностью в Firefox (его DOM-манипуляции гораздо медленнее? Firebug говорит, что большую часть времени тратит на jQuery.attr() - здесь не актуально), но похоже, что эта ошибка не замедляет меня; производительность одинакова до и после действия, которое вызовет замедление в Chrome. Опера тоже не пострадала.

Я еще не пробовал Safari и не могу тестировать на IE (сильная зависимость от SVG и другие проблемы).

Итак: у кого-нибудь есть идеи, что может повлиять на мое выступление? Или, по крайней мере, идея о том, какой эффект может иметь щелчок, если он не перехвачен обработчиком, и если изменение фокуса программы не делает то же самое? У меня закончились идеи для отладки этой вещи.

ОБНОВЛЕНИЕ : Полагаю, я все равно могу изолировать код. fileBrowser - это form (позже преобразованный в модальное диалоговое окно jQuery UI).

  var fileBrowserSubmit = function(evt) {
    // trigger the big render - either ~300ms or ~3s
  }
  var chooseDocument = function(evt) {
    // set up variables pertaining to the selected tr,
    // style the tr as selected
  }
  var chooseDocumentAndSubmit = function(evt) {
    chooseDocument(evt);
    fileBrowserSubmit(evt);
  }
  fileBrowser.
    submit(fileBrowserSubmit);
  fileBrowser.find('tr').
    click(chooseDocument).
    dblclick(chooseDocumentAndSubmit);

Если я нажимаю tr, затем нажимаю OK (таким образом, отправляя форму), никакого замедления: код, вызванный из fileBrowserSubmit, выполняется за ~ 300 мс

Если я дважды щелкну на tr, замедление: функция рендеринга будет работать в течение ~ 3 с (на примерах данных, на которых я тестирую).

Видно, что исполняемый код в обоих случаях практически идентичен: chooseDocument, за которым следует fileBrowserSubmit.

Answer 1

Используйте профилировщик.Это единственный способ убедиться.

Инструменты разработчика Chrome имеют один встроенный.

Answer 2

Вы должны собрать новый профиль ЦП Javascript на вкладке Профили.

1. Выберите "Собрать профиль ЦП JavaScript.
2. Нажмите Пуск.
3. Выполните некоторую операциюв вашем документе.
4. Нажмите Стоп.

Новый профиль будет создан в разделе «Профили ЦП» на боковой панели. Нажмите на него.

Answer 3

Хотя этот вопрос уже довольно старый, я столкнулся с той же проблемой.

Мое приложение также использует много SVG.После нажатия на некоторые (но не на все) элементы пользовательского интерфейса рендеринг занял гораздо больше времени.Использование профилировщика и временной шкалы из инструментов отладчика Chrome показало только, что вычисление offsetWidth (для расчета размера посторонних объектов в этом случае) занимало намного больше времени, чем раньше.Кроме того, вся статистика (потребление памяти, процессор и т. Д.) Была такой же, как и раньше.

Так как у меня уже была похожая проблема, которая была вызвана каким-то правилом CSS, я как бы грубо насиловалмои правила CSS.Правило, которое вызывало проблему, было (мой sass, использует twbs):

.some-component-selector {
    * {
       @include user-select(text);
    }
}

Для большей части, приложение не разрешает выбор пользователя, но в этом конкретном узле это делает.Прежде чем щелкнуть узел, кажется, что chrome просто обрабатывает узел как все остальные, но после того, как вы щелкнули по нему, svg рендерится очень медленно.Удаление этого правила устранило проблему для меня.

Я проверил это на версии 34.0.1847.116 на Mac, Windows и Linux, а также на некоторых версиях Chromium на Linux, и проблема существовала на всех платформах.