17370845950

b.N 是 Go 基准测试框架动态计算的执行次数配额，从 1 开始试跑并指数增长，使总耗时趋近 -benchtime（默认 1 秒），非手动设定常量。

什么是 b.N：它不是你写的循环次数，而是框架给你的“执行配额”

b.N 是 Go 基准测试框架自动计算并注入的整数值，表示当前轮次中被测代码**必须被执行的次数**。它不是常量，也不是你手动设的计数器——而是测试运行器根据实际耗时动态调整的结果，目标是让整个 BenchmarkXxx 函数总运行时间接近 -benchtime（默认 1 秒）。

• 框架从 b.N = 1 开始试跑，若耗时远小于 1 秒，就指数级增大（如 1 → 2 → 5 → 10 → 20 → 50…），直到单轮总耗时稳定在目标区间内
• 你写的 for i := 0; i 只是“消费”这个配额，不是定义逻辑边界
• 如果在循环里偷偷改了输入数据（比如原地排序后没重置），后续迭代就测的是已排序数组——结果完全失真

为什么不能把准备逻辑写在 for 循环里

常见错误：在 for i := 0; i 内部生成随机数据、初始化切片、调用 rand.Seed() 等——这些操作会被重复 b.N 次，严重污染耗时和内存统计。

• 准备动作（如 generate(10000, -100, 100)）必须放在循环外，只做一次
• 若每次迭代需要独立数据（比如避免排序算法复用已排好序的输入），应在循环内克隆或重新生成，但要用 b.ResetTimer() 排除准备开销
• 忘记 b.ResetTimer() 会导致“数据生成时间”被计入性能指标，出现 0.60 ns/op 这类明显反直觉结果

func BenchmarkSortSelection(b *testing.B) {
    // ✅ 准备一次，不计入计时
    data := generate(10000, -100, 100)
    
    b.ResetTimer() // ⚠️ 关键：从此刻开始计时
    
    for i := 0; i < b.N; i++ {
        // ✅ 每次都用新副本，避免副作用
        xs := append([]int(nil), data...) // 浅拷贝
        SortSelection(xs)
    }
}

b.N 的实际取值永远由框架决定，别硬编码也别猜

有人试图用 if b.N > 1000 { b.N = 1000 } 或直接写死 for i := 0; i ——这会让基准测试失效。Go 不会识别你的硬编码，它仍按自己节奏跑多轮，并可能因耗时过短而报 too fast 或给出极低的 ns/op。

• 命令行参数才是控制入口：go test -bench=. -benchtime=5s 让框架以 5 秒为目标调整 b.N
• -count=3 可重复运行整套基准三次，用于观察波动性；-benchmem 启用内存分配统计
• 编译器优化可能导致函数被内联或消除，记得把结果赋给全局变量（如 result = SortSelection(xs)），否则可能测出 “0 B/op” 和 “0 ns/op”

最容易被忽略的细节：随机数种子和数据复用

在 generate() 里反复调用 rand.Seed(time.Now().UnixNano()) 不仅慢，还会因纳秒级时间戳在快速循环中重复，导致生成相同序列——排序算法实际总在测同一组“幸运数据”，性能数字毫无参考价值。

• 正确做法：在 init() 或 Benchmark 函数开头设一次种子，或直接用固定种子保证可重现
• 更稳妥的做法：用 rand.New(rand.NewSource(123)) 创建局部伪随机器，避免全局 rand 包干扰
• 对排序类测试，建议每次迭代都用不同随机种子生成新数据，而不是复用一份——否则插入排序可能在第二轮就“撞上”几乎有序数组，性能虚高