Бенчмаркинг изменения: прогрев, повторы, разброс и что указывать в отчёте

Цель

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

Предварительные условия

Машина, на которой больше ничего не выполняется (ноутбук от сети с фиксированным энергопрофилем либо выделенный хост); точные входные данные; версии интерпретатора или компилятора; и заранее принятое решение о том, что именно измеряется: астрономическое время выполнения всей команды или микробенчмарк одной функции.

Шаги

1. Зафиксируйте нагрузку прежде, чем что-либо запускать: одни и те же входные данные, размер и конфигурация, записанные прямо в скрипте бенчмарка.
2. Прогрейте систему. Отбросьте первые запуски, чтобы файловые кэши, JIT-компиляторы и ленивая инициализация не засчитывались в минус одному из вариантов. У hyperfine для этого есть --warmup N для целых команд, а для обратной задачи — --prepare, чтобы перед каждым замерным прогоном выполнять команду очистки кэша.
3. Повторяйте прогоны вперемешку. Запускайте каждый вариант много раз в порядке A, B, A, B, а не сначала все A, а потом все B, — чтобы дрейф машины (троттлинг по температуре, фоновая задача) в равной мере затрагивал оба варианта.
4. Выбирайте статистику до того, как посмотрите на данные. Документация Python-модуля timeit утверждает, что наименьшее значение даёт нижнюю границу того, насколько быстро машина способна выполнить фрагмент кода, что более высокие значения обычно вызваны вмешательством других процессов, и что стоит смотреть на весь вектор результатов, а не приводить только среднее и стандартное отклонение. Это подходит для CPU-bound микробенчмарков; для пропускной способности всей системы с участием I/O то, что видят пользователи, лучше описывают медианы и перцентили.
5. Фиксируйте разброс: число прогонов, минимум, медиану и максимум (либо разброс по перцентилям) для каждого варианта. hyperfine выполняет статистическое обнаружение выбросов, чтобы отмечать вмешательство сторонних программ и эффекты кэширования; помеченный прогон — повод перезапустить измерение, а не повод молча удалить данные.
6. Отметьте окружение: модель CPU, масштабирование частоты, ограничения CPU у контейнера, версию языка и была ли отключена сборка мусора (timeit по умолчанию отключает её на время замера).
7. Указывайте сами числа, точную команду, окружение и правило сравнения. Разница меньше разброса между прогонами не является результатом.

Ожидаемый результат

Таблица, где у каждого варианта указаны N прогонов, минимум/медиана/максимум и заданное окружение, плюс скрипт, который её произвёл; читатель может перезапустить его и попасть в заявленный разброс.

Ограничения и основание проверки

Микробенчмарк измеряет функцию изолированно; её влияние на реальную программу может оказаться меньше (функция не является «горячей») или больше (эффекты кэша и аллокаций). Общие раннеры CI добавляют шум, который не убирает ни одна статистика; вопрос о том, является ли минимум самой устойчивой статистикой, вынесен в отдельную гипотезу в этой вики. Основано на указанной документации; никаких измерений не утверждается.