Простые стратегии отладки

В этой статье я собираюсь рассмотреть несколько простых стратегий, которые вы можете попробовать, если ваше приложение работает не так быстро, как вам хотелось бы.

Для контекста: в настоящее время я занят реализацией таблицы для проекта на работе. В таблице могут быть тысячи ячеек, в зависимости от того, сколько столбцов выберет пользователь, и каждая ячейка имеет довольно много функций, таких как возможность редактирования определенных ячеек, выделение текста при определенных условиях, анализ текстового содержимого как экранированного HTML-текста, и так далее. Таблица также предоставляет пользователю некоторые возможности, такие как выбор ячейки в следующей строке, когда пользователь редактирует строку и нажимает Enter.

Чтобы не реализовывать всю логику таблиц самостоятельно, я решил использовать библиотеку @tanstack/table, безголовую библиотеку таблиц, которая позволяет разработчику сосредоточиться на макете и функциональности таблиц, а не на мелочах таблицы, таких как переупорядочивание столбцов, строк. выделение и вложенные строки и заголовки столбцов.

Однако после реализации функции навигации по строке клавиши Enter я заметил одну проблему — она работала медленно! После нажатия Enter таблице потребовалось около 500 мс, чтобы выделить следующую редактируемую ячейку, что немыслимо для таблицы, написанной на одном из самых быстрых JS-фреймворков.

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

Вкладка производительности Devtools

Первая стратегия, которую я использовал, чтобы выяснить, где выполняется ненужная работа, заключалась в том, чтобы открыть вкладку производительности Chrome. На вкладке производительности нажмите кнопку записи и выполните действие, которое считается медленным. После завершения обработки вкладки «Производительность» вы можете просмотреть вкладку «снизу вверх», чтобы увидеть, на что тратится время.

В моем случае я заметил, что все ячейки анализировали экранированный текст HTML, а не только ячейки, содержащие экранированный текст HTML (обычно валюты). Это привело к заметным улучшениям, но кое-что еще предстояло сделать.

Обнаружение повторного рендеринга компонентов

Одно из ключевых различий между Solid и React заключается в том, что компоненты Solid «исчезают», тогда как компоненты React постоянно перезапускаются. Другими словами, это означает, что функция компонента в SolidJS должна выполняться только один раз, независимо от того, обновляются ли какие-либо данные, потребляемые компонентом.

В то время как неэффективность React «перезапустить все» компенсируется виртуальным DOM, если вы совершите те же грехи в Solid, вы будете наказаны за это более сурово.

Самый простой способ определить, выполняется ли компонент повторно, — просто добавить журнал консоли в тело функции компонента:

const EditableCell => (props) => {
  console.log("Editable Cell");
  return <input value={props.value} />
}

Теперь, если вы видите «Редактируемую ячейку» в журнале консоли после первоначального рендеринга, вы знаете, что что-то вызывает повторную визуализацию ваших ячеек.

Решение проблемы

В моем конкретном случае потребовалось два исправления. Во-первых, поскольку я использую tanstack/query в качестве слоя данных, который неизменно обновляет базовые данные, мне пришлось заменить компонент «For», повторяющий строки, на компонент «Key» из библиотеки solid-primitives. Компоненты Key аналогичны For, но позволяют передать ключ из элемента массива, чтобы сохранить идентичность вашего компонента. Таким образом, если у вас есть массив элементов, каждый из которых имеет поле идентификатора, если вы отображаете массив с помощью

<Key each={items} by={item => item.id}>
   {item => 
     <TableRow item={item()}
   }
</Key>

компоненты TableRow будут повторно использоваться вместо воссоздания, если вы передадите ему новый массив, содержащий элементы с теми же идентификаторами.

Второе исправление относится к утилите flexRender @tanstack/table. Я не уверен, почему, но это также заставляет ячейки перерисовываться, даже если строки стабильны. Поэтому вместо использования flexRender я вручную визуализирую правильный компонент ячейки на основе определения столбца. Пример проблемы и исправления можно посмотреть здесь: https://codesandbox.io/p/github/raymondboswel/solid-table-rendering-example

Заворачивать

На этом этапе мои познания в области отладки производительности исчерпываются. Я пытался посмотреть, могут ли инструменты Solid-dev предложить какие-либо дополнительные сведения, но, к сожалению, это было не так. В Интернете также не так много ресурсов по этой теме, поэтому, если у кого-то есть хорошие статьи по этой теме, я хотел бы увидеть их в комментариях.

Спасибо за прочтение!

Спасибо, что дочитали до конца. Пожалуйста, следите за автором и этой публикацией. Посетите Stackademic, чтобы узнать больше о том, как мы демократизируем бесплатное обучение программированию по всему миру.