17370845950

标准 Benchmark 函数不适合多组输入对比，因 testing.B 默认仅支持单次运行；需用 b.Run 实现表驱动基准测试，为每组参数生成独立性能指标，并注意正确调用 b.ResetTimer()、b.ReportAllocs() 等。

为什么标准 Benchmark 函数不适合多组输入对比

Go 的 testing.B 默认只允许单次运行一个基准函数，比如 BenchmarkFoo。如果你要对比不同参数组合（如不同字符串长度、不同 map 大小）下的性能，硬编码多个 Benchmark 函数会导致重复逻辑、难以维护，且无法共享 setup/teardown 代码。表驱动测试在单元测试中常见，但基准测试同样适用——关键是让 Run 方法嵌套进 Benchmark 函数里。

用 b.Run 驱动多个子基准测试

testing.B 提供了 Run 方法，支持动态命名和独立计时，这才是表驱动基准测试的核心。它会为每个子项生成独立的 ns/op、B/op 和 allocs/op，还能避免外层循环干扰内层计时逻辑。

常见错误是把数据循环写在 b.ResetTimer() 外面，导致 setup 时间被计入；或者忘记调用 b.ReportAllocs() 导致内存分配统计缺失。

• 子基准名必须是合法标识符（不能含空格或斜杠），建议用 fmt.Sprintf 构造，例如 "Len100"
• 每个子项内部必须调用 b.ResetTimer()（如果需要重置）和 b.StopTimer()（如果含非待测开销）
• 若需统计内存分配，应在顶层 Benchmark 函数开头调用 b.ReportAllocs()
• 不要在子项中调用 b.N 循环之外的耗时操作（如 time.Sleep），否则结果失真

func BenchmarkStringConcat(b *testing.B) {
	b.ReportAllocs()
	cases := []struct {
		name string
		n    int
	}{
		{"Len10", 10},
		{"Len100", 100},
		{"Len1000", 1000},
	}

	for _, c := range cases {
		b.Run(c.name, func(b *testing.B) {
			s := make([]string, c.n)
			for i := range s {
				s[i] = "x"
			}
			b.ResetTimer()
			for i := 0; i < b.N; i++ {
				_ = strings.Join(s, "")
			}
		})
	}
}

如何避免 b.N 被外层逻辑污染

b.N 是 Go 基准框架自动调整的迭代次数，目标是让总耗时接近 1 秒。如果在 b.Run 子函数里误把初始化放到了 b.N 循环内（比如反复创建大 slice），就会严重拖慢速度，导致 b.N 被压到极低值，最终 ns/op 失真。

正确做法是：所有预处理（如构建输入数据）放在 b.ResetTimer() 之前，或用 b.StopTimer() / b.StartTimer() 显式控制计时区间。

• 错误示例：for i := 0; i —— 每次都分配 1MB，计时包含分配开销
• 正确示例：data := make([]int, 1e6); b.ResetTimer(); for i := 0; i
• 更安全的写法：b.StopTimer(); data := make([]int, 1e6); b.StartTimer()，尤其适合 setup 成本高且不稳定的场景

运行与解读输出的关键细节

执行 go test -bench=. -benchmem 后，你会看到类似：

BenchmarkStringConcat/Len10-8          10000000               124 ns/op              96 B/op          1 allocs/op
BenchmarkStringConcat/Len100-8         1000000              1152 ns/op             976 B/op          1 allocs/op
BenchmarkStringConcat/Len1000-8         100000            11428 ns/op            9776 B/op          1 allocs/op

注意三点：

• 末尾的 -8 表示 GOMAXPROCS=8，不是 CPU 核心数，而是当前调度器配置；如需固定，加 -cpu=4
• 每行的 ns/op 是该子项独立测算的平均值，可直接横向对比
• 若某子项 allocs/op 突增，往往意味着逃逸分析失效或意外触发堆分配，值得用 go build -gcflags="-m" 检查

表驱动本身不解决算法复杂度问题，但它让差异暴露得更干净——尤其是当某个输入规模突然导致性能断层时，你一眼就能定位到临界点。