Причиной тяжеловесности был не Markdown, а веб-движок

Я оставил редактор Markdown открытым на ноутбуке. Хотя я ничего не вводил, вентилятор начал вращаться.

Сначала я подумал, что дело в Markdown. Что редактор работает медленно, потому что постоянно перерисовывает документ.

Но так ли это на самом деле?

Я сравнил их в одинаковых условиях

Я сделал одинаковыми размер экрана, способ рендеринга и документ. Я открыл документ размером 7,5 КБ из 113 строк и ничего не делал в течение 25 секунд. При наборе текста я также вводил одни и те же символы с одинаковой скоростью.

В режиме простоя apostrophe, отображающий предварительный просмотр с помощью веб-движка, использовал 34,6% процессора и 378 МБ памяти. При этом работало пять процессов.

Прототип, который отображал тот же документ в строке без веб-движка, использовал 0,7% процессора и 64 МБ памяти. Процесс был всего один.

Оба отображали Markdown, но результаты сильно различались.

Когда я отключил в apostrophe только предварительный просмотр, использование процессора снизилось до 7,0%, а памяти — до 133 МБ. И приложение, и инструментарий остались прежними. Изменился лишь способ отображения предварительного просмотра.

Я также измерил текстовый редактор, который вообще не отображал Markdown. Он использовал 2,2% процессора и 79 МБ памяти.

Прототип, отображавший Markdown, оказался даже легче.

Тогда всё стало ясно. Проблема была не в Markdown.

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

Причина заключалась в коде, синхронизирующем прокрутку предварительного просмотра с основным текстом.

Этот код выполнялся не только во время прокрутки. Каждые 16 мс таймер пробуждался и запускал JavaScript в процессе WebKit. Когда приходил ответ, таймер запускался снова.

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

При использовании веб-движка область редактирования документа и область отображения предварительного просмотра оказываются в разных мирах. Самый простой способ синхронизировать два состояния — постоянно их проверять. Если отдельно не измерять использование процессора в режиме простоя, эти затраты трудно заметить.

При наборе текста разница становилась ещё больше. apostrophe использовал 180% процессора, а прототип — 41%.

В одном случае каждое нажатие клавиши проходило туда и обратно через процесс браузера. В другом теги повторно применялись только к изменённой строке.

Результаты измерений стали принципами проектирования

В прототипе не было особых оптимизаций.

Стили накладывались на текст с помощью тегов. Несколько операций редактирования объединялись в одну одноразовую idle-задачу, которая сама исчезала. Повторное применение тегов ограничивалось изменёнными строками. Использовался только один процесс.

Дело было не в том, что мы что-то добавили, а в том, что мы не оставили ничего ненужного.

После этого мы установили два принципа проектирования.

Во-первых, не включать веб-движок в зависимости.

Во-вторых, если документ не меняется и анимации нет, не планировать кадры, таймеры и тики.

Эти принципы трудно применить задним числом. Веб-движок — не просто библиотека: он меняет архитектуру приложения. Если однажды его добавить, его удаление фактически превращается в создание приложения заново. А если не установить правил для таймеров, их становится на один больше с каждой новой функцией.

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

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

При интерпретации чисел тоже нужно соблюдать осторожность

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

Даже 0,7% процессора, использованные прототипом в режиме простоя, в основном приходились на мигание курсора. Если отключить мигание, значение было трудно отличить от нуля.

Это не означает, что все приложения на основе веб-движков сталкиваются с той же проблемой. Эти результаты относятся только к apostrophe. Существуют и движки, которые сокращают объём работы в режиме простоя, например основанные на Chromium.

У прототипа также было не так много функций. В нём не было таблиц, формул, экспорта и поиска. Сравнивать можно только затраты на рендеринг.

Но одно было очевидно.

Затраты создавал не Markdown. Их создавали движок рендеринга и непрерывно работающий цикл.

Если точно найти причину, легковесность становится не новой функцией, а результатом вычитания.