Почему Monosnap стал таким медленным — и решение

Налог Electron, усугубленный

Monosnap не’начинал как приложение Electron. В начале своего существования большая часть кода для захвата и редактирования была нативной. Со временем компоненты пользовательского интерфейса были перестроены на основе рендерера Chromium — что упростило их итерацию, но добавило значительные, постоянные затраты на запуск.

Electron со временем не’становится легче. Каждый год Chromium добавляет функции, поставляя больше кода, увеличивая базовое потребление памяти и усложняя инициализацию. Приложение, которое было приемлемым 60 МБ в 2019 году, теперь занимает минимум 180 МБ при запуске, и это число растет. Это’без учета утечки памяти, которую мы рассмотрели на странице об утечке памяти.

Когда вы нажимаете Ctrl+Alt+5, Monosnap должен прогреть рендерер Chromium, чтобы отобразить оверлей захвата. В холодном приложении это’занимает несколько сотен миллисекунд. В уже запущенном приложении, которое уже заняло сотни мегабайт, это’дольше. К пятому часу рабочего дня наложение отрисовывается достаточно медленно, чтобы пользователи могли заметить разницу.

Редактор аннотаций — самая проблемная часть

Окно редактора после захвата почти полностью представляет собой веб-представление Chromium. Когда вы добавляете стрелку или рисуете прямоугольник, инструмент отправляет события через Electron’через границу IPC в нативный процесс и обратно. Этот круговой путь быстр в свежем процессе и заметно замедляется, когда процесс загружен.

Для пользователей, активно использующих аннотации — отчеты об ошибках, учебные пособия, документация — это накапливается. Десять минут аннотирования ощущаются как двадцать.

Maxisnap: без Electron, без накладных расходов

Maxisnap’редактор — это нативное окно PyQt6. Холст для аннотаций использует QPainter непосредственно на QPixmap.’нет веб-представления, нет границы IPC между логикой инструмента и поверхностью рендеринга. Когда вы добавляете стрелку, она появляется в следующем цикле отрисовки. Нет кругового пути.

Холодный запуск из трея до готовности к захвату занимает около секунды на типичной машине. Захват-в-редактор занимает менее 200 мс. Эти показатели остаются неизменными через 1, 4, 8 и 72 часа. Приложение не’деградирует со временем, потому что’нечего накапливать.