Почему вместо слов «лёгкий» мы публикуем цифры

Markdown-редакторы часто представляют так.

Быстрый. Лёгкий. Плавный.

Но если у цифр не указаны условия, они ничем не отличаются от прилагательных. Когда и как долго измерялась загрузка CPU в режиме простоя. От какого до какого момента рассчитывалось время запуска. Потому что числа, полученные в разных условиях, сравнивать нельзя.

Поэтому мы определили 8 показателей производительности, которые публикует mote. Для каждого показателя мы записали метод и условия измерения, исключения, правила сравнения, предостережения и бюджет. И связали каждый из них со скриптом измерения.

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

У цифр должны быть условия

mote придерживается четырёх принципов.

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

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

Мы сравниваем результаты только на одной машине и в рамках одной сессии. Числа, полученные в разные дни или на разных устройствах, мы не ставим рядом.

Условия измерения мы также публикуем вместе с числами. В частности, всегда указываем частоту обновления экрана и регулятор частоты CPU. Если эти условия различаются, задержку и время запуска нельзя корректно сравнивать.

Мы не изобретали новые методы измерения.

Задержка от ввода с клавиатуры до изменения изображения на экране измеряется точно так же, как в Typometer Павла Фатина. Клавиша нажимается извне приложения, после чего отслеживается момент изменения пикселя. Время запуска мы, как и VS Code, разделили на этапы и разграничили холодный и тёплый запуск.

Принцип, согласно которому задержку нужно измерять от начала до конца, а не внутри фреймворка, мы взяли из статьи Дэна Луу.

Мы сравнили приложения сами в одинаковых условиях

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

Мы открывали один и тот же документ размером 100KB и запускали каждое приложение по 7 раз с помощью одного и того же скрипта. Во всех приложениях использовался режим встроенного редактирования, а указатель находился в одном и том же месте.

Общее потребление памяти всеми процессами выглядело так.

• mote: 78MB
• Typora: 453MB
• Obsidian: 361MB
• MarkText: 416MB

Загрузка CPU при наборе текста в пересчёте на одно ядро составила 10.9%, 103%, 152% и 136% соответственно. Количество процессов составило 1, 8, 7 и 6 соответственно.

mote использовал в 4.6–5.8 раза меньше памяти. При наборе текста он использовал в 9.4–14 раз меньше ресурсов CPU.

Память рассчитывалась по PSS, а не по RSS. RSS может учитывать общую для нескольких процессов память несколько раз. PSS распределяет общую память между процессами. Так же работает и системный монитор.

Неудобные цифры мы тоже оставили как есть

Когда приложения были просто открыты, загрузка CPU составляла 0.0% у mote, 0.1% у Typora, 0.8% у Obsidian и 0.6% у MarkText.

В режиме простоя Typora тоже почти не использовала CPU. Поэтому мы не можем преподносить способность «ничего не делать, пока приложение просто открыто» как преимущество перед Typora.

Веб-оболочка использовала 3.6%, то есть показала себя даже хуже Typora.

Устранять циклические таймеры внутри приложения по-прежнему важно. Но принцип, которого следует придерживаться, и конкурентное преимущество — это разные вещи.

Количество кадров в режиме простоя мы не сравнивали с конкурирующими приложениями. Целевой показатель mote — 0 кадров за 10 секунд, но в других приложениях нет счётчика кадров, который позволял бы проверить это тем же способом.

Поэтому поля для конкурирующих приложений мы оставили пустыми. Пустое поле — не ноль.

Если сравнение невозможно, мы не сравниваем

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

mote проверяет 652 примера CommonMark. Кроме того, мы открываем и повторно сохраняем все документы в репозитории, а затем проверяем их побайтовое совпадение. Если отличается хотя бы один байт, мы считаем это не проблемой производительности, а ошибкой, приводящей к потере данных.

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

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

Это правило появилось после того, как мы столкнулись с неудачей.

Мы измерили время запуска, оставив открытым браузер, который активно использовал CPU, и получили результаты, создававшие впечатление ухудшения производительности. Когда мы стали поочерёдно измерять предыдущий и текущий коммиты при одинаковой нагрузке, выяснилось, что причиной была не регрессия в коде, а нагрузка на машину.

С тех пор мы не оцениваем время запуска только по одному абсолютному значению.

Если бюджет превышен, изменения нельзя смержить

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

Критерии делятся на hard и report.

hard — это показатели, числовые значения которых зафиксированы в документах с решениями. Если хотя бы один из них превышает предел, проверка завершается неудачей. Отдельного согласования исключений тоже нет.

report — это показатели, для которых пока недостаточно обоснований или которые сильно зависят от ограничений платформы. Их значения записываются, но не блокируют сборку.

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

Скрипты измерения, исходные CSV и итоговые JSON хранятся вместе в репозитории. Если запустить тот же скрипт в тех же условиях, таблицу можно создать заново. Мы также готовимся опубликовать инструменты измерения и тестовые документы в открытом репозитории бенчмарков.

Публиковать только хорошие цифры — это не открытость.

Показать вместе, что и как измерялось, какими были условия и что измерить не удалось. Именно так mote публикует свои цифры.