Бенчмарк в миллисекундах: автор советует целиться в 300 мс

В заметке «Benchmark In Milliseconds» разбирается вопрос, сколько должен длиться микробенчмарк. Личное правило автора: подбирать размер входных данных, пока бенчмарк не начнёт занимать около 300 мс. Это ориентир, а не стандарт.

Довода четыре. Первый: миллисекунды, целые числа от 1 до 999. Этого достаточно, чтобы заметить даже небольшое улучшение, а столбец таких чисел легко просматривать глазами. Не нужны ни разные единицы, ни дробные значения; автор предлагает сравнить 1,31 с и 239 мс.

Второй довод: всё, что быстрее, скажем, 10 мс, рискует исказиться из-за постоянных издержек, например запуска интерпретатора. Сотни миллисекунд для компьютера, «целая вечность», обычно их достаточно, чтобы разовые накладные расходы перестали иметь значение. Не нужны более хитрые приёмы, которые учитывают эти расходы явно; по словам автора, такие приёмы менее надёжны.

Третий довод связан с человеческим восприятием. Сотни миллисекунд, это быстро, но заметно. Когда числа попадают в доступный человеку диапазон, можно опираться на интуитивное чувство времени и скорости, а не только на арифметику. Автор добавляет, что это просто приятно: после оптимизации видно, как раньше подтормаживавшая команда командной строки становится «мгновенной».

Четвёртый довод, верхняя граница. Если бенчмарк идёт дольше секунды, итерации над ним замедляются сильнее, чем нужно. Запустить его 10 раз подряд, чтобы на глаз оценить разброс, должно быть быстро.

Итоговая предпосылка: цель бенчмаркинга, не столько точно измерить производительность, сколько дать автору достаточно интуиции, чтобы принять правильное решение. Замеров, результатов и ссылок на исследования в заметке нет: это личная рабочая эвристика.

Ключевые факты

  • Правило автора: подбирать размер входных данных, пока микробенчмарк не займёт около 300 мс.
  • Миллисекунды, целые числа от 1 до 999: достаточно точности, удобно просматривать, не нужны дроби и смена единиц (сравнение 1,31 с и 239 мс).
  • Быстрее примерно 10 мс (число приведено как пример) бенчмарк рискует исказиться постоянными издержками, например запуском интерпретатора.
  • Дольше секунды итерации над бенчмарком замедляются; 10 запусков подряд для оценки разброса должны быть быстрыми.
  • Исходная предпосылка: бенчмарк нужен, чтобы дать интуицию для верного решения, а не для точного измерения.

Почему это важно

Вопрос, сколько должен идти микробенчмарк, возникает постоянно, а единого ответа в заметке не обещают. Автор делится личной эвристикой и объясняет её четырьмя практическими доводами: удобство чтения чисел, подавление разовых издержек, работа с человеческой интуицией и скорость итераций. Новых измерений или исследований здесь нет, ценность в ясно сформулированном рабочем правиле.

Кому это важно

Разработчикам, которые пишут и оптимизируют код и сами замеряют скорость небольших фрагментов или команд командной строки. В заметке упомянуты запуск интерпретатора и «лагавшая» CLI-команда, но конкретные языки и инструменты не называются.

Как это применить

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

Можно ли доверять

Это личное мнение автора блога, а не стандарт или результат исследования. Цифра 300 мс подана как «около», порог 10 мс, как пример («скажем»). Эмпирических данных или ссылок на исследования в тексте нет, так что считать правило универсальным нельзя.

Риски и подводные камни

Автор прямо оговаривает исходную предпосылку: цель бенчмаркинга здесь, дать интуицию для верного решения, а не точно измерить производительность. Когда нужна именно точность, правило может не подойти. Кроме того, автор говорит, что более сложные приёмы учёта разовых издержек менее надёжны, но в тексте это не подкреплено примерами.

«Цель бенчмаркинга, не столько точно измерить производительность, сколько дать автору достаточно интуиции, чтобы принять правильное решение.»

— из заметки «Benchmark In Milliseconds»