Go testing.B怎样让基准测试报告自定义指标怎样完成一个可复用的最小示例

我在给排序、解析这类基准补充“每次操作做了多少工作”时，最容易踩的坑不是不会调用 testing.B，而是把累计值、单次值和计时混在一起。Go 的 b.ReportMetric 正好解决了这个问题：在基准主体完成后，把自定义数值和无空白单位写入标准基准报告。

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

核心做法是先在循环中累计业务指标，结束后按指标含义除以 b.N 或 b.Elapsed()，再调用 b.ReportMetric。单位要稳定、不能含空白，重复上报同一单位时后一次会覆盖前一次。

先把“总量”和“每次操作”分开

默认的 ns/op 是测试框架根据计时得到的结果，但排序比较次数、解析字段数、命中条数等业务指标并不会自动出现。它们通常先以总量累加，最后再换算成每次基准操作的平均值。

下面的示例用一个小切片排序，并把比较次数报告为 compares/op。代码使用当前文档推荐的 b.Loop 组织新基准；如果维护旧代码，也可以把循环条件换成 i 。

package bench

import (
    "cmp"
    "slices"
    "testing"
)

func BenchmarkSortCompareCount(b *testing.B) {
    var compares int64

    for b.Loop() {
        values := []int{5, 4, 3, 2, 1}
        slices.SortFunc(values, func(a, z int) int {
            // 每次比较都累加，循环外再换算成每个操作的平均值。
            compares++
            return cmp.Compare(a, z)
        })
    }

    // compares 是总量，/op 表示要报告每次操作的平均值。
    b.ReportMetric(float64(compares)/float64(b.N), "compares/op")
}

运行方式是 go test -bench=SortCompareCount -benchmem。输出会保留框架生成的 ns/op，并额外出现 compares/op；-benchmem 还会显示分配相关的内置指标。这里的重点是指标写入报告，不是用 fmt.Println 打印一行难以被基准工具消费的文本。

单位决定了读者如何解释数字

ReportMetric 的第二个参数不是装饰文本，而是结果字段的一部分。按操作统计时，使用 compares/op、items/op 这样的无空白单位；按时间统计时，可以使用 compares/ns，计算分母则应来自 b.Elapsed() 的纳秒数。

func BenchmarkParseReport(b *testing.B) {
    input := []byte("id=17&name=go")
    var fields int64

    for b.Loop() {
        // 这里仅演示业务计数，实际解析函数应返回真实字段数量。
        fields += int64(countFields(input))
    }

    // 每次操作的字段数适合 /op；不要把总字段数直接报成平均值。
    b.ReportMetric(float64(fields)/float64(b.N), "fields/op")
    // 处理速度按经过的纳秒统计，单位与分母保持一致。
    b.ReportMetric(float64(fields)/float64(b.Elapsed().Nanoseconds()), "fields/ns")
}

func countFields(input []byte) int {
    // 示例函数只返回分隔后的字段数量，避免把解析细节混入指标说明。
    if len(input) == 0 {
        return 0
    }
    return 2
}

单位必须非空，也不能包含空格或换行，否则会触发 panic。另一个容易忽略的行为是：同一个单位再次上报时会覆盖之前的值。因此可以先计算好最终结果，再对每个单位调用一次，避免同一指标在不同分支中留下难以判断的结果。

并行基准要先解决计数竞争

在 b.RunParallel 中，多个 goroutine 会共同完成 b.N 次迭代。普通的 int64++ 会产生数据竞争，最终的自定义指标可能偏小；应使用原子计数，并且等并行工作全部结束后再上报。

import (
    "sync/atomic"
    "testing"
)

func BenchmarkParallelCompareCount(b *testing.B) {
    var compares atomic.Int64

    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            // 并行 goroutine 共享计数器，必须使用原子加法。
            compares.Add(1)
        }
    })

    // RunParallel 返回后再读取总量，避免报告中途的部分结果。
    b.ReportMetric(float64(compares.Load())/float64(b.N), "calls/op")
}

这个片段需要额外导入 sync/atomic。并行基准中的 ns/op 是整个并行基准的墙钟时间口径，自定义的 calls/op 则是所有 goroutine 合计次数除以总迭代数，二者不能混成“每个 goroutine 的速度”。

我会保留的三个检查点

• 指标是总量还是每次操作：总量先累计，/op 指标通常除以 b.N。
• 计时是否包含了不该测的工作：准备数据可以放在第一次 b.Loop 之前；旧式 b.N 循环则按需要调用 ResetTimer。
• 并行数据是否安全：共享计数使用原子操作，RunParallel 返回后再读取并上报。

如果只需要吞吐量，b.SetBytes 会让框架补充 MB/s；如果需要业务维度，就用 ReportMetric。两者可以并存，关键是让单位和分母能让读者一眼看懂。

相关问题

ReportMetric 能修改默认的 ns/op 吗？可以。对同名单位上报会覆盖旧值；把 ns/op 设为 0 还能抑制该内置指标，但一般不建议隐藏默认耗时。

为什么自定义指标显示不稳定？先确认分母是否正确，再确认并行计数没有数据竞争，并避免把准备阶段或清理阶段混入计时。

旧项目必须改成 b.Loop 吗？不必为了本题强行改造。旧式 b.N 循环仍可调用 ReportMetric，但新写的基准优先考虑 b.Loop，以减少重复执行准备和清理逻辑的误解。