Краткий ответ

Используйте отдельные подбенчмарки через b.Run — по одному на каждую реализацию. Go независимо подберёт b.N для каждого подбенчмарка и выведет раздельные значения времени, аллокаций и других показателей.

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

Исторический контекст

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

Такой подход решает проблему смешанных измерений: каждый вариант становится самостоятельным benchmark-кейсом, который тестовый фреймворк может калибровать отдельно.

Постановка проблемы

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

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

Подробное решение

Передайте каждой реализации собственную функцию в b.Run. Каждый вызов создаёт отдельный подбенчмарк с независимым значением b.N; поэтому число итераций для дешёвой и дорогой реализации может отличаться.

package bench

import (
    "bytes"
    "testing"
)

var sink int

func BenchmarkCount(b *testing.B) {
    data := bytes.Repeat([]byte("a"), 1024)
    b.Run("bytes", func(b *testing.B) {
        for i := 0; i < b.N; i++ { sink = bytes.Count(data, []byte("a")) }
    })
    b.Run("manual", func(b *testing.B) {
        for i := 0; i < b.N; i++ {
            n := 0; for _, x := range data { if x == 'a' { n++ } }; sink = n
        }
    })
}

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

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

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

Ситуация из практики

Команда сравнивала два способа сериализации, вызывая оба способа подряд в одном benchmark-цикле. Отчёт показывал только суммарное время; кроме того, вторая реализация получала данные, частично оставшиеся в процессорном кэше после первой.

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

Выбрали b.Run с отдельной подготовкой входов и глобальным sink для результата. В итоге команда получила самостоятельные значения ns/op для каждого алгоритма и смогла отдельно проверить результаты несколькими запусками. Для оценки именно производительности смешанной нагрузки оставили отдельный сценарий, не подменяя им сравнительный benchmark.

Что кандидаты часто упускают

Одинаково ли значение b.N у всех подбенчмарков?

Нет. Каждый подbenchmark калибруется отдельно, поэтому b.N может существенно различаться. Это нормально: фреймворк стремится получить измерение достаточной длительности для каждого варианта, а не заставить их выполнить одинаковое число итераций.

Нужно ли останавливать таймер для подготовки данных внутри b.Run?

Да, если подготовка не входит в измеряемую операцию. Иначе её стоимость попадёт в результат конкретного варианта и сравнение будет измерять не только алгоритм. Если же в реальной системе подготовка является частью рабочего сценария, исключать её не следует — важно измерять именно заявленный контракт benchmark.

Гарантируют ли отдельные подбенчмарки полностью честное сравнение?

Нет. Они разделяют метрики и калибровку, но не устраняют влияние окружения, сборщика мусора, частоты CPU, кэшей и аллокаций. Для повышения надёжности используют одинаковые данные, отсутствие межвариантных побочных эффектов, несколько запусков и сравнение изменений в сопоставимых условиях.