17370845950

Go中用sub-benchmark对比函数性能的核心是通过testing.B.Run在单个Benchmark内组织多个子测试，共享初始化逻辑以避免重复开销，确保公平比较算法执行效率。

在 Go 中用 sub-benchmark（子基准测试）对比函数性能，核心是利用 testing.B.Run 在同一个 Benchmark 函数内组织多个可比的子测试，共享相同的数据准备逻辑，避免重复初始化开销，从而更公平地反映算法本身的执行效率。

用 Run 方法定义结构化子基准测试

Go 的 testing.B 支持通过 b.Run(name, fn) 创建命名子测试。每个子测试独立计时、独立运行多次（由 -benchtime 和自动调整的迭代数决定），且默认并行执行（除非显式禁用）。关键在于：所有子测试共用外层基准函数中的预处理代码（如生成输入数据），确保比较基础一致。

• 把耗时的初始化（如构造大 slice、解析 JSON、构建树结构）放在 b.Run 外部
• 每个 b.Run 内只放待测函数调用和核心逻辑，不重复准备输入
• 子测试名应体现算法特征（如 "SortSlice"、"SortSliceStable"），便于识别

控制输入规模与避免编译器优化干扰

子基准测试中，若输入数据固定或太小，编译器可能内联、常量折叠甚至完全消除调用；若每次运行都重新生成数据，又会污染测量结果。正确做法是：

• 在 b.Run 外一次性生成足够大的输入（例如 data := make([]int, b.N) 或更大固定尺寸）
• 子测试内部用 b.N 控制循环次数，但函数调用需真正消费输入（如传入切片并排序）
• 对返回值做简单使用（如 sum += result[i]），防止被优化掉；可用 blackbox 模式（赋值给全局变量或调用 runtime.KeepAlive）

示例：对比两种切片求和实现

以下是一个完整可运行的 benchmark 示例：

func BenchmarkSumMethods(b *testing.B) {
    // 一次性生成大输入，避免重复分配
    data := make([]int, 10000)
    for i := range data {
        data[i] = i
    }

    b.Run("Loop", func(b *testing.B) {
        var sum int
        for i := 0; i < b.N; i++ {
            sum = 0
            for _, v := range data {
                sum += v
            }
        }
        // 防止优化：使用结果（可选）
        blackBox(sum)
    })

    b.Run("Reduce", func(b *testing.B) {
        var sum int
        for i := 0; i < b.N; i++ {
            sum = reduceInts(data)
        }
        blackBox(sum)
    })
}

func reduceInts(s []int) int {
    sum := 0
    for _, v := range s {
        sum += v
    }
    return sum
}

// 黑盒函数，阻止编译器丢弃结果
var blackBoxResult int
func blackBox(x int) {
    blackBoxResult = x
}

运行与解读结果

执行 go test -bench=BenchmarkSumMethods -benchmem，输出类似：

BenchmarkSumMethods/Loop-8         10000000               124 ns/op            0 B/op          0 allocs/op
BenchmarkSumMethods/Reduce-8       10000000               126 ns/op            0 B/op          0 allocs/op

注意两点：

• 两行的 ns/op 值接近，说明实际性能差异微小；若某子测试慢 2 倍以上，就值得深入分析（如是否意外触发 GC、内存拷贝或低效分支）
• Benchmem 显示内存分配情况，对判断是否产生逃逸、中间对象开销非常关键

不复杂但容易忽略：子 benchmark 不是“多写几个 BenchmarkXXX 函数”，而是用 Run 构建受控、可复现、零干扰的横向对比环境。真正影响结论的，往往是数据准备方式和结果使用方式，而不是算法本身那几行代码。