Day 042 — ベンチマーク駆動最適化（コードレビュー: ループ内での正規表現再コンパイル）

📚 背景知識（読んでから問題へ）

Day 038〜041では、pprofを使ってCPU/メモリの「どこが重いか」を見つける方法を学びました。今回のテーマ「ベンチマーク駆動最適化」は、その一歩先です。問題箇所を見つけた後、実際に直して、直したことで本当に速くなった（あるいはアロケーションが減った）ことを数値で証明するワークフローを扱います。

Goのtestingパッケージにはtesting.Bというベンチマーク専用の型があり、go test -bench=.で実行できます。ポイントはb.Nです。これは「Goのベンチマークフレームワークが自動的に調整する繰り返し回数」で、開発者が決めるものではありません。フレームワークは実行時間が安定して測定できるまでb.Nを増やしながら何度も実行します。さらに-benchmemフラグを付けると、ns/op（1回あたりの実行時間）に加えてB/op（1回あたりの確保バイト数）とallocs/op（1回あたりのアロケーション回数）も出力されます。

📝 問題

以下は、メールアドレスの形式を検証する関数IsValidEmailSlowのコードレビュー依頼です。この関数は、Webアプリケーションのリクエストバリデーションの中で、リクエストが来るたびに何度も呼ばれる関数だとします。

📋 コピーpackage validator

import "regexp"

// IsValidEmailSlow はリクエストごとに呼ばれるメールアドレス検証関数。
func IsValidEmailSlow(s string) bool {
	re := regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
	return re.MatchString(s)
}

1. このコードのパフォーマンス上の問題点を、regexp.MustCompileが何をしているかに触れながら指摘する
2. testing.Bを使い、go test -bench=. -benchmemでこの関数の現状のBenchmarkコードを書く（実行はしなくてよいが、go testでそのまま動く完全なコードにすること）
3. 問題点を修正したIsValidEmailFastを実装する
4. Before/Afterの両方をベンチマークし、ns/op・B/op・allocs/opの3指標がそれぞれどう変化するはずかを、コードの構造から論理的に予測する
5. 「ループの中で毎回コンパイルする」という同種のアンチパターンが、正規表現以外にどんな標準ライブラリ・処理で起こりうるか、最低2つ挙げる

🔍 ヒント（段階的開示）

📋 コピーpackage validator

import "regexp"

// パッケージ初期化時（プログラム起動時）に一度だけ実行される
var emailPattern = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)

func IsValidEmailFast(s string) bool {
	return emailPattern.MatchString(s) // コンパイル済みのものを使い回すだけ
}

📋 コピーfunc BenchmarkXxx(b *testing.B) {
	b.ReportAllocs() // -benchmem 相当の情報を明示的に有効化する（-benchmemフラグと併用可）
	for i := 0; i < b.N; i++ {
		// 計測したい処理
	}
}

✅ 模範解答

validator.go（Before/After 両方を1ファイルに置く。実務ではAfterのみ残しBeforeは削除する）

📋 コピーpackage validator

import "regexp"

// IsValidEmailSlow は「レビュー対象」のBefore実装。
// 呼び出されるたびに regexp.MustCompile でパターンをコンパイルし直している。
func IsValidEmailSlow(s string) bool {
	re := regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
	return re.MatchString(s)
}

// emailPattern はパッケージ初期化時に一度だけコンパイルされる。
var emailPattern = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)

// IsValidEmailFast はAfter実装。コンパイル済みの正規表現を使い回す。
func IsValidEmailFast(s string) bool {
	return emailPattern.MatchString(s)
}

validator_test.go

📋 コピーpackage validator

import "testing"

// 動作が変わっていないことを先に保証する（最適化で挙動を壊していないかの担保）
func TestIsValidEmail(t *testing.T) {
	cases := []struct {
		in   string
		want bool
	}{
		{"a@example.com", true},
		{"not-an-email", false},
	}
	for _, c := range cases {
		if got := IsValidEmailSlow(c.in); got != c.want {
			t.Errorf("Slow(%q) = %v, want %v", c.in, got, c.want)
		}
		if got := IsValidEmailFast(c.in); got != c.want {
			t.Errorf("Fast(%q) = %v, want %v", c.in, got, c.want)
		}
	}
}

func BenchmarkIsValidEmailSlow(b *testing.B) {
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		IsValidEmailSlow("user@example.com")
	}
}

func BenchmarkIsValidEmailFast(b *testing.B) {
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		IsValidEmailFast("user@example.com")
	}
}

実行コマンドと実測結果（go test -bench=. -benchmem -run=^$。-run=^$は通常のテストをスキップしベンチマークだけ走らせる指定）:

📋 コピーgoos: darwin
goarch: amd64
pkg: validator
cpu: VirtualApple @ 2.50GHz
BenchmarkIsValidEmailSlow-8   	  232021	      4441 ns/op	    5858 B/op	      66 allocs/op
BenchmarkIsValidEmailFast-8   	 2958976	       411.5 ns/op	       0 B/op	       0 allocs/op
PASS

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

🏆 実務での使いどころ

• 正規表現・テンプレート・SQLプリペアドステートメントのグローバル初期化: リクエストハンドラの中でregexp.MustCompileやtemplate.Parse、db.Prepareを毎回呼んでいないか、コードレビューの定番チェック項目にする
• リリース前のBefore/Afterベンチマーク添付: パフォーマンス改善のPull Requestには、修正前後のgo test -bench=. -benchmemの出力を貼り付ける運用にすると、レビュアーが体感ではなく数値で改善を判断できる
• CIでのベンチマーク回帰検知: benchstatで複数回の実行結果を統計的に比較し、意図しない性能劣化（regression）をリリース前に検出するパイプラインに組み込む

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: go install golang.org/x/perf/cmd/benchstat@latestでbenchstatを導入し、同じベンチマークを複数回（-count=10など）実行した結果を統計的に比較し、「誤差の範囲内か、有意な差か」を判定する練習をしてみましょう
• 次回予告: reflectパッケージ — 「なぜリフレクションは遅いのか」を、今回学んだベンチマーク手法を使って自分で実測しながら理解します

🎯 自己評価

自分の回答

気づき・メモ