Go testing.B 怎样拆分基准测试样本

把短字符串、长字符串和空输入都塞进同一个 BenchmarkParse，最后只得到一个平均数字，通常无法回答“哪个场景变慢了”。testing.B 的 Run 方法可以把一次基准拆成多个有名字的子基准；每个子基准单独执行自己的 b.N 次迭代，结果也能按场景比较。

拆分样本的关键不是多写几个函数，而是先定义场景边界，再让 b.Run 管理每个场景的测量范围。准备输入的代码放在计时开始前，被测调用放在循环内。

本文只讨论样本分组和计时范围。示例使用标准库 testing，官方文档地址为 https://pkg.go.dev/testing。

先把不同输入场景写成数据边界

假设要比较解析器处理空文本、短文本和长文本的成本。最先要固定的不是循环次数，而是每个场景的名称与输入。名称会出现在基准输出中，输入则应该在进入计时循环前准备好。

package parser

import "testing"

// parseText 代表待测函数；这里不把输入构造放进它的计时范围。
func parseText(input string) int {
	return len(input)
}

func BenchmarkParseText(b *testing.B) {
	// 每一项对应一个可单独比较的用户场景。
	cases := []struct {
		name  string
		input string
	}{
		{name: "empty", input: ""},
		{name: "short", input: "go benchmark"},
		{name: "long", input: "go benchmark with a longer payload for parsing"},
	}

	for _, tc := range cases {
		b.Run(tc.name, func(b *testing.B) {
			// 将每个场景的输入绑定到子基准，避免循环变量语义干扰阅读。
			input := tc.input
			b.ResetTimer()
			for i := 0; i 

这里的 empty、short 和 long 是三条数据边界，不是三次手工复制的基准函数。将来增加“unicode”或“含分隔符”等场景时，只需增加一项数据，输出仍保持同一层级。

用 b.Run 让每个样本拥有独立结果

b.Run(name, func(b *testing.B)) 建立的是子基准边界。父级函数负责组织样本，子函数收到新的 *testing.B，循环中的 b.N 也属于当前样本。调用带有子基准后，父基准不会再被当作一个普通样本单独计时，因此不要再从父级输出里寻找一个“总平均值”。

保存为 parser_test.go 后，可以用下面的命令只观察这组基准：

# 运行名称以 BenchmarkParseText 开头的基准，并打印每个子样本。
go test -run '^$' -bench '^BenchmarkParseText$' -benchmem ./...

输出中的名称通常会带上 /empty、/short 和 /long。这使得“长文本是否更慢”成为一个可直接定位的问题，而不是从混合平均值反推。

把准备数据移出真正的计时范围

子基准内部也要分清“准备”和“测量”。如果每次迭代都拼接输入、分配临时切片或查找样本，那么结果测到的是“准备加解析”，而不是解析函数本身。可以在循环前创建稳定输入，再用 ResetTimer 清掉前置工作的计时影响。

func BenchmarkLookup(b *testing.B) {
	// 这些数据只为构造场景，不能让准备成本混入目标函数。
	keys := []string{"alpha", "beta", "gamma"}
	index := map[string]int{"alpha": 1, "beta": 2, "gamma": 3}

	b.Run("three-keys", func(b *testing.B) {
		// 子基准开始前完成数据准备，再清零计时器。
		query := append([]string(nil), keys...)
		b.ResetTimer()
		for i := 0; i 

ResetTimer 只影响当前子基准的计时与分配计数，不会替代样本设计。若你确实想研究“构造输入加查找”的端到端成本，就保留准备代码并在标题或场景名中明确它的含义。

看结果时避免把不同问题重新混在一起

拆分完成后，先比较同一函数不同样本的 ns/op，再决定是否需要增加更多维度。不要仅因为某个子基准更快，就断言它在所有输入和机器上都更快；基准结果会受数据规模、编译器、CPU 和运行环境影响。

• 场景名要描述输入边界，例如 empty、short、long，避免使用无法解释的编号。
• 准备数据应在计时循环外完成；如果准备成本就是研究对象，应在名称中写出来。
• 父基准只负责分组，真正的迭代次数和结果应看子基准的 b.N 与输出行。

常见问题是把 b.Run 和 b.RunParallel 混为一谈：前者解决样本分组，后者解决并行执行模型，本文不把两者混用。另一个误区是为每个场景复制一份基准函数，这会让计时边界逐渐漂移，优先用同一组表驱动数据保持结构一致。

相关问题

父级 Benchmark 还会有一个总的 ns/op 吗？

当父级调用了 b.Run 时，父级本身不会作为普通基准样本测量，重点应放在各个子基准的输出。

什么时候不该把样本拆成子基准？

如果所有输入边界、准备成本和目标路径都相同，拆分只会增加噪声；只有当你需要独立比较不同场景时，子基准名称才真正有价值。