Go testing.B.SetBytes 怎样让基准结果显示吞吐量

我在给文件读取和编码基准补结果字段时，最先遇到的不是代码跑不起来，而是结果看不出“每秒处理了多少数据”。只有 ns/op 时，读者还要自己拿输入长度去换算吞吐量。testing.B.SetBytes 就是为这个场景准备的：告诉基准框架一次操作处理多少字节，输出里就会同时出现 ns/op 和 MB/s。

官方文档：https://pkg.go.dev/testing#B.SetBytes

调用`b.SetBytes(n)`方法就可以把基准测试单次循环处理的字节总数上报给Go testing框架，最终输出结果里就会自动生成带每秒吞吐量（throughput）的统计行，不用自己额外手动计算 throughput 字段。

SetBytes 到底告诉基准框架什么

b.SetBytes(n) 记录的是“单次操作处理的字节数”。当基准函数调用它后，Go 基准结果会保留每次操作耗时 ns/op，并基于 n 计算吞吐量 MB/s。它不会替你测量额外的网络流量，也不会把循环次数本身当成字节数。

可以把换算关系写成：MB/s = bytesPerOperation ÷ nsPerOperation × 1000。这里使用十进制 MB。比如一次操作处理 1,048,576 字节，测得每次耗时 1,000,000 纳秒，吞吐量就是约 1048.576 MB/s。这个数字只是公式示意，不代表某台机器的实测结果。

为什么结果里会多出 MB/s

没有调用 SetBytes 时，框架不知道一次迭代对应多少数据，通常只能报告耗时和分配相关字段。调用 b.SetBytes(int64(len(input))) 后，框架才知道每轮的字节口径，于是可以在同一行结果里补充吞吐量。

这不意味着 B/op 会被替换。B/op 关注每次操作产生的内存分配字节数，MB/s 关注每秒处理的业务数据量，两者的“字节”不是同一个口径。

把输入规模绑定到真正的被测操作

文件、编码或压缩基准通常已经有一份固定输入。把它的长度传给 SetBytes，然后让循环每次处理这份输入，结果才有稳定含义。使用当前 Go 文档推荐的 b.Loop 写法时，可以这样组织：

func BenchmarkDecode(b *testing.B) {
	// 固定输入只准备一次，避免把样本构造成本混进每次操作。
	input := make([]byte, 64

关键点有两个：SetBytes 的参数必须和一次实际处理的数据量一致；它可以放在计时循环前，因为它只是设置报告元数据。输入准备是否计时，则由基准代码的计时边界决定，不要把这两个问题混在一起。

旧式 b.N 写法也要保持同一口径

如果项目仍使用传统的 b.N 循环，原则不变。每次迭代都处理同样大小的输入，并在循环前声明这个大小：

func BenchmarkEncode(b *testing.B) {
	// 让每轮编码面对相同的输入，避免输入长度变化影响吞吐量。
	input := bytes.Repeat([]byte("go"), 32

如果每轮处理的大小会变化，就不能随便用一个固定长度冒充吞吐量。可以把不同规模拆成独立子基准，让每个子基准分别调用自己的 SetBytes，这样名称和结果可以一一对应。

运行结果时怎样同时看吞吐量和分配

通常用 -benchmem 把分配字段一起显示。命令本身不改变 SetBytes 的含义，只是要求测试框架把内存统计也列出来：

# 只运行基准，不运行普通测试，并显示每次操作的分配统计。
go test -run '^$' -bench 'BenchmarkDecode|BenchmarkEncode' -benchmem ./...

阅读结果时可以按这个顺序判断：

几个容易让吞吐量失真的边界

第一，SetBytes 的参数不能写成 len(input) * b.N。框架报告的是每次操作的速率，循环总字节数已经由迭代次数体现，再乘一次会把结果放大。

第二，如果函数只处理输入的一部分，就应传入实际处理的那一部分字节数，而不是整个切片长度。相反，如果一次调用会处理两段输入，声明值也应反映两段的总量。

第三，输入内容在循环中被修改时，要确认每轮仍然代表相同的工作量。否则 MB/s 可能看起来稳定，实际测量的工作却已经变化。

第四，并发基准要单独解释结果。官方文档指出 RunParallel 报告的是整个并行基准的 wall time，不是所有 goroutine 耗时简单相加；此时 SetBytes 仍是单次操作口径，但吞吐量应结合并发模型阅读。

我的结论：把 MB/s 当作数据口径，不当作唯一成绩

对文件、编码、压缩、哈希这类“处理了多少数据”比“调用了多少次”更重要的基准，SetBytes 很值得加。它把输入规模和 ns/op 放到同一份结果里，减少手算，也方便比较不同大小的场景。

但它不能替代 ns/op、B/op 或 allocs/op。我通常先确认每轮工作量一致，再一起看这几个字段；如果只是为了让输出出现一个漂亮的 MB/s，而没有把字节口径定义清楚，结果反而更容易误导。

相关问题

SetBytes 的 n 是整个测试处理的总字节数吗？

不是。它表示单次操作处理的字节数。基准执行了多少次由框架管理，不能把 b.N 乘进 SetBytes。

调用 SetBytes 后还会显示 ns/op 吗？

会。SetBytes 在结果中增加吞吐量报告，不会把每次操作耗时字段改成别的单位。

为什么我的 MB/s 很高但 B/op 也很高？

两者衡量对象不同：前者是业务数据处理速率，后者是每次操作的堆分配字节数。吞吐量高不代表分配成本低，需要结合输入规模和分配字段一起判断。

可以用 SetBytes 统计 HTTP 响应大小吗？

可以，但要先定义一次操作是处理固定响应、请求体还是实际读取到的有效字节。若每次响应大小变化，建议按大小拆分子基准，避免用一个平均值掩盖场景差异。