Проблема с производительностью в Letta Desktop оказалась не в циклах или неоптимизированном коде, а в том, как устроен scrollHeight в браузере. Автор разбирался, почему приложение тормозит по мере накопления сообщений — чем больше данных, тем сильнее падала скорость. Виновником стала простая строка: el.scrollTop = el.scrollHeight. Она заставляла интерфейс постоянно прокручиваться вниз при новых сообщениях.
Логика подсказывала, что scrollHeight — это readonly-свойство, которое обновляется только при отрисовке, а не при каждом чтении. Но оказалось, что браузер пересчитывает его на каждом обращении. В исходном коде Chromium метод scrollHeight() вызывает UpdateStyleAndLayoutForNode — то есть принудительно запускает перекомпоновку (layout). Каждый раз, когда скрипт читает scrollHeight, браузер обновляет стили и макет для этого элемента.
Для потокового приёма сообщений, где требуется постоянно крутить скролл вниз, это убийственно. scrollHeight меняется каждый раз, когда появляется новое сообщение, а частый вызов scrollTop = scrollHeight создаёт лавину вычислений.
Автор признаёт, что даже если бы реализация была другой — например, свойство кешировалось и обновлялось по триггеру — проблема осталась бы. Но главный урок: readonly-свойства в браузере не гарантируют быстродействия. Особенно когда их значение динамическое и очевидно зависит от содержимого.
Решение нашлось простое: вместо точного scrollHeight подставлять очень большое число — скажем, 999999. Браузер сам обрежет его до фактической высоты контента при скролле. Прокрутка стала работать быстро, никаких лишних пересчётов макета при чтении свойства.