Go 1.24 で追加された testing.B.Loop を使ってベンチマークテストを書いてみる

はじめに

Go でベンチマークテストを行うにあたり、1.24 で新しく testing.B.Loop が追加されているためそちらの動作を確認してみました。

testing.B.Loop() について

b.Loop() はベンチマークのイテレーションをランタイムが制御する新しい記法です。

従来の b.N ループとの主な違いをざっと整理すると以下のような内容のようです。

---

従来の書き方 (b.N ループ)

シンプルな定義をすると以下のようなイメージになります。

func BenchmarkOld(b *testing.B) {
    for i := 0; i < b.N; i++ {
        strings.ToUpper("hello, world")
    }
}

初期化処理などが必要な場合は、ループ外に配置したうえで b.ResetTimer() を呼び出す必要がありました。 ※が、ここで、b.ResetTimer() を忘れると初期化処理の時間も計測に含まれてしまうため注意が必要でした。

func BenchmarkOldWithSetup(b *testing.B) {
    f, err := os.CreateTemp("", "bench_old_*.txt")
    if err != nil {
        b.Fatal(err)
    }
    defer os.Remove(f.Name())
    defer f.Close()

    b.ResetTimer() // 初期化処理の時間を計測から除外するために必要
    for i := 0; i < b.N; i++ {
        if _, err := f.WriteString("hello\n"); err != nil {
            b.Fatal(err)
        }
    }
}

b.N ループではベンチマーク関数全体が繰り返し呼ばれるため、初期化処理などは毎回実行されます。

仮に初期化処理がやや重い処理の場合は、無駄なリソース消費に加え、テスト実行時間が予想よりも長くなってしまったりもします。

---

新しい書き方 (b.Loop())

b.Loop() を使うと、同じベンチマークをより簡潔に書けます。

func BenchmarkNew(b *testing.B) {
    for b.Loop() {
        strings.ToUpper("hello, world")
    }
}

初期化処理がある場合でも b.ResetTimer() は不要になります。

計測時の認識漏れを防げるのは勿論、「ループの外 = 計測対象外」という対応がコード構造と一致するため、意図が自然に伝わるのは嬉しい点です。

func BenchmarkNewWithSetup(b *testing.B) {
    f, err := os.CreateTemp("", "bench_new_*.txt")
    if err != nil {
        b.Fatal(err)
    }
    defer os.Remove(f.Name())
    defer f.Close()

    // b.ResetTimer() 不要
    for b.Loop() {
        if _, err := f.WriteString("hello\n"); err != nil {
            b.Fatal(err)
        }
    }
}

また、b.Loop() を使うことで従来のように初期化処理が毎回実行されることはなくなるため、消費リソースの節約やテスト時間の短縮にもつながるのは良さそうです。

More predictable benchmarking with testing.B.Loop

b.Loop can simply run the benchmark loop until it reaches the time threshold, and only needs to call the benchmark function once.

---

ベンチマーク結果

Apple M5 / Go 1.26.1 で実測した結果です。

BenchmarkOld-10               46335399    24.42 ns/op    16 B/op    1 allocs/op
BenchmarkNew-10               47398275    24.55 ns/op    16 B/op    1 allocs/op
BenchmarkOldWithSetup-10       1000000  1002   ns/op     0 B/op     0 allocs/op
BenchmarkNewWithSetup-10       1235643   969.6 ns/op     0 B/op     0 allocs/op

BenchmarkOld と BenchmarkNew はほぼ同等のパフォーマンスです。 b.Loop() のメリットはパフォーマンスの改善ではなく、記述の簡潔さと可読性にあると認識しています。

---

導入の背景

そもそもの testing.B.Loop() の導入背景についても少し気になったので調べてみました。

1. b.N の使い忘れ

ベンチマーク関数が b.N を参照しないケースが広く存在しており、vet で検出は可能ではあるものの見落としやすい状況だったことが課題として上がっていたようです。 (golang/go#38677)

testing パッケージは b.N を段階的に増やしながらベンチマーク関数を繰り返し呼び出し、実行時間が収束したところで1回の処理にかかった時間 (ns/op) を算出します。

ここでの注意点として、以下のような b.N を参照しないコードは b.N の値に関わらず常に 1000 回しか実行されません。

func BenchmarkFoo(b *testing.B) {
    for i := 0; i < 1000; i++ { // 常に 1000 回固定
        doSomething()
    }
}

// BenchmarkFoo-10    1000000    24.42 ns/op

b.N を参照しないコードは反復回数が固定されたままになるため、b.N の値によって ns/op が変わり、計測結果に再現性がなくなってしまうことが考えられます。

正しい場合

• b.N = 1,000,000 のとき、ループも 1,000,000 回実行される。
• 実行時間 = 1回あたり 24 ns × 1,000,000 回 = 24,000,000 ns
• ns/op = 24,000,000 ÷ 1,000,000 = 24 ns/op

誤った場合

• b.N の値に関わらず、ループは常に 1,000 回しか実行されない。

本来は 24 ns/op であるべきところが、b.N の値によって 0.024 〜 24,000 まで大きくブレます。

しかも出力の形式は正常に見えるため、数値を疑わなければ気づけません。

※なお、この issue#38677 はvet を検出しようといった類の提案のように見えるのですが、根本的な解決策として b.Loop() を設計することにつながったようです。

2. b.N をループ回数ではなく「処理する件数」として使われてしまう

testing: add testing.B.Loop for iteration の Issue の例がわかりやすかったです。

there’s some evidence that many benchmarks use b.N incorrectly, such as using it to size the input to an algorithm, rather than as an iteration count.

// 誤った使い方の例
func BenchmarkFoo(b *testing.B) {
    data := make([]int, b.N) // b.N をデータサイズに使っている
    for i := range data {
        doSomething(data[i])
    }
}

// 正しい使い方の例
func BenchmarkFoo(b *testing.B) {
    data := make([]int, 1000) // サイズは固定
    for i := 0; i < b.N; i++ { // b.N 回繰り返す
        doSomething(data[i%len(data)])
    }
}

誤ったほうの書き方だと、testing パッケージが b.N = 1,000,000 に増やしたとき、100 万件のデータを 1 回処理することになってしまうためよくありません。

また、b.N が変わるたびに処理する件数も変わるため、ns/op の意味が一定にならない状態になってしまうことを課題として挙げているように見えました。

3. b.ResetTimer() の必要性

こちらは前述した内容の通りです。

また、Issue や公式にも経緯などが明記されています。

testing: add testing.B.Loop for iteration

Because the benchmark framework doesn’t know when the b.N loop starts, if a benchmark has any non-trivial setup, it’s important for it to use (*testing.B).ResetTimer. It’s generally not clear what counts as non-trivial setup, and very hard to detect when ResetTimer is necessary.

More predictable benchmarking with testing.B.Loop

If setup or cleanup are non-trivial, the developer needs to surround the benchmark loop with ResetTimer and/or StopTimer calls. These are easy to forget, and even if the developer remembers they may be necessary, it can be difficult to judge whether setup or cleanup are “expensive enough” to require them.

初期化処理が計測対象に含まれないようにループの外で b.ResetTimer() を呼び出す必要がありましたが、漏れやすく気づきにくいという課題があったのが主な理由のようです。

また、初期化処理自体が比較的重い処理の場合はなんとなく検知できるチャンスはあるかもしれませんが、軽い処理の場合は数値を見てもほぼ気づけません。

4. 初期化処理が複数回実行されてしまう

testing パッケージは適切な b.N を見つけるためにベンチマーク関数を複数回呼び出します。

よって初期化処理自体のコストが高い場合(例: DBの初期化など)、予想よりも実行時間が伸びてしまう点も課題としてあったようです。

// この関数自体が b.N により何度も呼び出されることになる
func BenchmarkFoo(b *testing.B) {
    db := connectDB() // 1秒かかる重い処理
    defer db.Close()

    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        db.Query("SELECT 1")
    }
}

上記の場合、b.Nが収束するまでに4回呼び出されるとすると、初期化処理だけで4秒かかります。

仮に -benchtime=1s を指定していても、実際の総実行時間は意図より大幅に伸びてしまうためあまり無視できない問題であったようです。

---

おわりに

今回は Go 1.24 で追加された testing.B.Loop のコーディング例や動作、導入に至った経緯などを見ていきました。

意図が曖昧なものをできる限り減らしよりシンプルに記述できるようになったのはGoらしいなと思いつつ、実行時のパフォーマンスにも手が加えられている点は個人的には嬉しい機能でした。

余裕があれば導入に至った経緯などを深ぼるのもまた面白かったりします。

ほかにも新たに加えられた機能などもあるのでどこかでまた調査して行けたらと思います。

---

参考

• Go 1.24 Release Notes - New benchmark function
• pkg.go.dev - testing.B.Loop
• Go Blog - More predictable benchmarking with testing.B.Loop