testing.BenchmarkTimer 控制基准测试的计时范围

Go 基准测试里最常见的误差，不是算法真的变慢，而是把造数据、复制切片、清理临时状态也算进了 ns/op。直接结论是：标题里的 testing.BenchmarkTimer 可以理解为“基准计时器”这一检索概念，Go 实际并没有导出同名类型；计时能力在 *testing.B 上，通过 B.Loop、StopTimer、StartTimer 和 ResetTimer 控制。

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

B.Loop 说明：https://go.dev/blog/testing-b-loop

先澄清：计时能力实际在 testing.B 上

testing.B 是基准函数收到的对象。Go 测试框架会在调用基准函数前自动启动计时，因此普通代码一进入基准函数就可能处于计时状态。B.StartTimer 恢复被暂停的计时，B.StopTimer 暂停计时，B.ResetTimer 则把已经累计的耗时、分配计数和用户指标清零，但不改变“正在计时还是暂停”的状态。

B.Elapsed() 返回的也是当前有效计时范围对应的累计时间。把这些方法看成同一个 testing.B 对象上的状态控制，比想象成一个独立的 BenchmarkTimer 类型更准确。

Go 1.24 后先用 B.Loop 划定外层计时

Go 1.24 引入 B.Loop。第一次进入循环时，它会重置计时器；循环结束后，它会停止计时。因此，循环前的固定初始化和循环后的清理自然不进入统计范围。一个基准函数通常只放一个 B.Loop，并让每次迭代执行同一种被测操作。

func BenchmarkLookup(b *testing.B) {
    // 一次性构造只读索引；B.Loop 会把循环外准备排除在计时外。
    index := buildIndex(10_000)

    for b.Loop() {
        // 循环体只保留真正需要测量的查询操作。
        _ = index.Lookup("gopher")
    }
}

这种写法比手动维护 b.N 更不容易把初始化成本混入结果，也避免编译器把无关循环变量处理影响到基准结构。它解决的是“循环外准备”的边界，而不是自动识别循环体里哪一行属于准备动作。

每轮准备数据时手动暂停和恢复

排序、解码、写缓冲区等操作会改变输入。如果每轮都复用已经排序或已经消费的数据，第二轮开始测到的就不是同一个任务。正确做法是保留稳定模板，在每轮里先暂停计时、恢复工作副本，再恢复计时并执行被测操作。

func BenchmarkSortInts(b *testing.B) {
    // 模板只构造一次，避免随机数生成影响排序结果。
    source := make([]int, 4096)
    for i := range source {
        source[i] = len(source) - i
    }
    work := make([]int, len(source))

    for b.Loop() {
        b.StopTimer()
        // 每轮恢复同样的未排序输入，这段复制成本不进入 ns/op。
        copy(work, source)
        b.StartTimer()

        // 这里只测量排序本身。
        slices.Sort(work)
    }
}

关键不是“准备代码一定要少”，而是每轮的计时边界必须一致。若准备过程本身就是你要比较的对象，例如比较两种反序列化方案的完整端到端成本，就不应该暂停计时。

ResetTimer、StopTimer、StartTimer 各自负责什么

最容易写错的是在暂停状态下调用 ResetTimer，然后误以为它会自动恢复。它不会；需要继续计时时仍要调用 StartTimer。反过来，计时器正在运行时调用 ResetTimer，清零后会继续运行。

旧版 b.N 写法如何迁移

在还不能使用 Go 1.24 的项目里，传统写法仍可工作，但要显式在初始化后清零。下面的 ResetTimer 会删除构造夹具产生的累计指标，随后计时继续运行。

func BenchmarkEncodeLegacy(b *testing.B) {
    // 先构造固定夹具；这个成本不属于编码吞吐量。
    fixture := buildFixture()
    b.ResetTimer()

    for i := 0; i 

迁移到 B.Loop 时，循环外的 ResetTimer 通常可以删除，因为第一次调用 B.Loop 会处理外层计时边界。但如果每轮都有准备动作，手动的暂停和恢复仍然需要保留。

为什么结果仍可能忽高忽低

• 输入状态不一致：第一次排序后没有恢复原始数据，后续测到的是近乎有序输入。
• 暂停范围过大：把本应属于真实请求路径的分配、解析或锁等待排除了。
• 恢复位置太晚：真正的被测调用之前还有缓存查询或参数转换没有计入。
• 每轮工作不同：某些迭代命中缓存，另一些迭代走慢路径，结果自然抖动。
• 把一次性初始化放进循环：即使暂停计时，也可能改变缓存、GC 和内存压力，间接影响结果。

建议先把“每次迭代要完成的业务任务”写成一句话，再据此决定哪些成本应计入。计时器不是用来让数字更漂亮，而是让测量范围与要回答的问题一致。

RunParallel 中不要调用这些计时方法

RunParallel 会并发执行工作函数，而 StartTimer、StopTimer 和 ResetTimer 对整个基准对象产生全局影响。一个 goroutine 暂停计时会影响其他 goroutine，因此官方文档明确不建议在并行工作函数中使用这些方法。

func BenchmarkCacheParallel(b *testing.B) {
    // 并行运行前完成共享只读数据的准备。
    cache := buildCache()

    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            // 并行循环里只执行同一种操作，不修改全局计时状态。
            _ = cache.Get("gopher")
        }
    })
}

如果并行场景必须包含每次请求的准备成本，就把它视为操作的一部分；如果必须排除复杂准备，优先在进入 RunParallel 前构造不可变数据，或重新设计基准以避免跨 goroutine 的全局计时切换。

常见问题

有 testing.BenchmarkTimer 这个类型吗？

没有公开导出的同名类型。Go 用户通常用这个词描述 benchmark 的计时能力，实际接口是 testing.B 上的方法。

B.Loop 会自动排除循环体里的准备代码吗？

不会。它自动处理循环前后边界；每轮准备仍需手动调用 StopTimer 和 StartTimer。

ResetTimer 后还要 StartTimer 吗？

取决于调用前状态。ResetTimer 不改变运行状态；如果之前已经暂停，就必须显式恢复。

应该排除 GC 吗？

不要为了数字好看而随意排除。若分配和 GC 是真实操作的一部分，应保留；只有与问题无关的夹具构造才应移出或暂停计时。

控制基准测试计时范围的核心，是先定义要测量的任务，再让代码边界与问题边界一致：一次性准备放在 B.Loop 外，每轮重建用暂停与恢复包住，旧式写法用 ResetTimer 清零，而并行基准不要修改全局计时状态。这样得到的 ns/op 才真正可比较。