Бенчмарки и детектор гонок в Go

Как устроен бенчмарк

Функция BenchmarkXxx(b *testing.B) прогоняет измеряемый код b.N раз, а пакет testing сам подбирает N: гоняет функцию заново со всё большим числом итераций, пока суммарное время не дотянет до заданного. Запуск - go test -bench=.

Отсюда неочевидное следствие про подготовку. Я сравнил два бенчмарка: в одном заполнение массива на двадцать миллионов элементов попало в замер, в другом было вырезано через b.ResetTimer. Разница вышла всего 2 процента, 78 946 против 77 268 наносекунд, потому что подготовка поделилась почти на четыре тысячи итераций.

// ResetTimer поэтому важен там, где операция медленная и b.N остаётся маленьким, или когда подготовку приходится делать внутри цикла - тогда её закрывают парой b.StopTimer и b.StartTimer.

b.N

число итераций, пакет testing подбирает его сам

b.ResetTimer

исключает подготовку из замера

Компилятор выбрасывает то, что не нужно

Два одинаковых бенчмарка, разница в одной строке. В первом результат функции никуда не девается, во втором уезжает в пакетную переменную. Замер: 0,395 наносекунды против 0,789. Ровно вдвое быстрее - потому что в первом случае компилятор выкинул вызов целиком, и меряли пустой цикл.

Ноль целых четыре десятых наносекунды на операцию это примерно один такт процессора. Такое число само по себе сигнал: если бенчмарк показывает единицы десятых наносекунды, скорее всего меряется не то, что задумано.

// Лечится присваиванием результата пакетной переменной. Локальная не спасёт - компилятор увидит, что она никому не нужна, и всё равно выбросит вычисление.

мёртвый код

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

пакетная переменная

приёмник результата, который нельзя выбросить

Аллокации и цена детектора

Флаг -benchmem (или b.ReportAllocs в коде) добавляет колонки B/op и allocs/op - байты и число аллокаций на операцию. Часто именно они объясняют результат: код медленный из-за мусора, который потом убирает сборщик, а не из-за вычислений. Так и меряют оптимизацию - убрали боксинг, задали вместимость слайсу, смотрим, упало ли allocs/op.

Флаг -race решает другую задачу: инструментирует обращения к памяти и ловит гонки, которые реально случились в этом запуске. Анализ динамический, поэтому непройденная ветка останется непроверенной, а зелёный прогон отсутствия гонок не доказывает.

// Цена детектора: в документации говорят о типичном замедлении около десяти раз, у меня на микробенчмарке блокировки вышло тридцать семь - 14,9 наносекунды превратились в 548,6. Микробенчмарк - худший случай, но вывод один: -race живёт в CI и на нагрузочном стенде, не в проде.

allocs/op

число аллокаций на операцию, часто главный виновник

-race

динамический детектор гонок, дорогой по времени

Как отвечать: «Как меряете производительность и зачем -race?»

Бенчмарком из стандартного пакета: функция BenchmarkXxx получает *testing.B и прогоняет измеряемый код b.N раз, причём число итераций пакет подбирает сам, наращивая его до нужного суммарного времени. Первое, за чем слежу - чтобы компилятор не выбросил измеряемое. Я это проверял: два одинаковых бенчмарка, в одном результат никуда не идёт, в другом уезжает в пакетную переменную, и первый вышел ровно вдвое быстрее, 0,395 наносекунды против 0,789, потому что мерил пустой цикл. Второе - обязательно смотрю аллокации через -benchmem, колонки B/op и allocs/op, они часто и объясняют разницу: код тормозит из-за мусора, а не из-за вычислений. Третье - один прогон за истину не принимаю. Восемь прогонов одного и того же бенчмарка у меня разошлись на 21 процент, от 0,616 до 0,749, поэтому гоняю с -count и сравниваю через benchstat. Подготовку вырезаю через b.ResetTimer, хотя тут стоит понимать механику: пакет прогоняет функцию заново с растущим b.N, так что подготовка делится на все итерации, и заметна она в основном на медленных операциях. Детектор -race про другое: он ловит гонки данных, инструментируя обращения к памяти, работает динамически и потому зелёным результатом ничего не доказывает. Замедление у меня доходило до тридцати семи раз, поэтому его место в CI, а не в проде.

Сильный ответ: назван механизм b.N, показано главное практическое требование - следить за мёртвым кодом, аллокации подняты как объясняющий фактор, учтён статистический разброс с конкретным процентом и корректно очерчено, что доказывает и чего не доказывает -race.

На чём валят

• −Принимают один прогон за истину. У меня восемь прогонов разошлись на 21 процент.
• −Забывают присвоить результат, и компилятор выбрасывает измеряемый код: 0,395 против 0,789 наносекунды.
• −Ставят b.ResetTimer как ритуал, не понимая, что подготовка делится на b.N.
• −Смотрят только на время и не замечают allocs/op в -benchmem.
• −Считают, что зелёный прогон с -race доказывает отсутствие гонок.