B.Loop 基准测试怎样比较不同缓冲区大小

比较不同缓冲区大小时，最稳妥的结构是：用 b.Run 为每个大小创建独立子基准，用 for b.Loop() 驱动同一段复制操作，把缓冲区分配放在循环外复用，再用 b.SetBytes 和 b.ReportAllocs 同时观察 MB/s、ns/op、B/op 与 allocs/op。

如果测的是 io.CopyBuffer，还必须避免源实现 io.WriterTo 或目标实现 io.ReaderFrom。官方文档明确说明，只要任一快速路径存在，传入的缓冲区就不会用于复制；此时即使子基准名字不同，也没有真正比较缓冲区大小。

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

io.CopyBuffer 官方文档：https://pkg.go.dev/io#CopyBuffer

先固定负载：缓冲区大小之外的条件必须相同

我在看缓冲区基准时，最先检查的不是候选值，而是每个子基准处理的数据是否一样。小缓冲区如果只复制小文件，大缓冲区却复制大文件，最后得到的并不是选型依据，而是两种负载的混合结果。

下面把每次操作的输入固定为 1 MiB，并选择四个常见候选：1 KiB、4 KiB、32 KiB 和 128 KiB。1 MiB 明显大于最大缓冲区，可以让每个候选都经历多次读写；同时所有子基准使用同一份只读 payload，避免数据内容变化。

完整基准：用 B.Run 隔离候选，用 B.Loop 驱动测量

下面的测试文件可以直接放进包内的 *_test.go。外层循环只负责枚举候选，b.Run 为每个大小建立独立的统计结果；每个子基准内部再使用自己的 b.Loop。

package bufferbench

import (
    "bytes"
    "fmt"
    "io"
    "testing"
)

// readerOnly 只暴露 io.Reader，避免 bytes.Reader 的 WriterTo 快速路径。
type readerOnly struct {
    io.Reader
}

// writerOnly 只暴露 io.Writer，避免目标端的 ReaderFrom 快速路径。
type writerOnly struct {
    io.Writer
}

func BenchmarkCopyBuffer(b *testing.B) {
    // 生成固定 1 MiB 输入；父基准只负责组织子基准，不测量自身。
    payload := bytes.Repeat([]byte("0123456789abcdef"), 64>10)
        b.Run(name, func(b *testing.B) {
            // 每个候选复用独立 Reader、Writer 视图和缓冲区。
            src := bytes.NewReader(payload)
            srcView := readerOnly{Reader: src}
            dstView := writerOnly{Writer: io.Discard}
            buf := make([]byte, size)

            // 记录每次操作处理的字节数，并启用内存分配指标。
            b.SetBytes(int64(len(payload)))
            b.ReportAllocs()

            for b.Loop() {
                // 只重置读取位置，不重新分配 payload 或 buffer。
                src.Reset(payload)
                if _, err := io.CopyBuffer(dstView, srcView, buf); err != nil {
                    b.Fatal(err)
                }
            }
        })
    }
}

B.Loop 第一次调用会重置计时器，返回 false 时会停止计时器，因此 payload、候选表、Reader 和 buffer 的创建不计入结果。这样测到的是“复用既有缓冲区搬运固定数据”的成本，适合连接池、对象池或长生命周期流处理器的选型。

为什么要隐藏 WriterTo 和 ReaderFrom

io.CopyBuffer 并不保证总会使用你传入的 buf。如果源实现 WriterTo，复制会走源端优化；否则如果目标实现 ReaderFrom，会走目标端优化。只有两者都没有时，通用复制路径才会使用自定义缓冲区。

*bytes.Reader 本身实现了 WriteTo。如果直接把它传给 CopyBuffer，四个子基准可能都绕过 buf。示例中的 readerOnly 与 writerOnly 通过接口收窄，只暴露基础的 Read 和 Write 方法，保证比较对象确实是 1 KiB、4 KiB、32 KiB、128 KiB 四个缓冲区。

这个处理也揭示了一个重要取舍：如果生产代码实际依赖 WriterTo 或 ReaderFrom 快速路径，那么“强制通用缓冲区路径”的结果并不能代表真实生产性能。此时应分成两组基准：一组测真实类型与真实快速路径，另一组才专门研究通用复制路径的 buffer 大小。

运行方式：重复测量，不要只看一次最快值

建议固定机器负载后运行多轮，并保留内存指标：

# 只运行 CopyBuffer 基准，固定每轮测量时间，并重复 5 次观察波动。
go test -run='^$' -bench='BenchmarkCopyBuffer' -benchmem -benchtime=1s -count=5

每个子基准会形成独立名称，例如 BenchmarkCopyBuffer/1KiB。判断时不要只挑某一轮最低的 ns/op，而应同时看：

• MB/s：相同 payload 下越高，单位时间搬运的数据越多。
• ns/op：完成一次 1 MiB 复制所需时间，越低越好。
• B/op：每次操作分配的字节数。缓冲区放在循环外后，这一项应主要反映复制路径自身。
• allocs/op：每次操作的分配次数，用来识别某个候选是否触发额外分配。
• 重复波动：如果某个大小偶尔第一、偶尔垫底，差异可能小于系统噪声。

b.SetBytes(int64(len(payload))) 告诉测试框架每次操作处理多少字节，因此输出会增加 MB/s。它不会改变循环次数，也不会自动判断哪个大小最好。

缓冲区并非越大越好：把单次速度放回并发预算

单个 goroutine 的最优值不一定是服务端的最优值。假设每个活跃请求都独占一个 128 KiB buffer，几千个并发请求会放大常驻内存和 GC 压力；32 KiB 即使在微基准中略慢，也可能因为内存占用更稳而更适合高并发。

我通常按下面的约束做选择，而不是直接接受“最大缓冲区最快”：

文章里的内存复制基准适合筛掉明显不合适的候选，却不能替代真实文件系统、TLS、网络带宽和连接并发下的端到端测试。推荐先用它缩小到两个候选，再把两个候选放进真实负载复测。

两种测量目标不要混在一起

上面的代码把 make([]byte, size) 放在 B.Loop 外，回答的是“复用缓冲区时哪个大小搬运更合适”。如果业务每次请求都会新建 buffer，那么分配成本本身就是负载的一部分，应该另写一个基准，把分配放进循环体，而不是悄悄修改现有基准。

func BenchmarkBufferAllocation(b *testing.B) {
    for _, size := range []int{1 >10), func(b *testing.B) {
            b.ReportAllocs()
            for b.Loop() {
                // 此基准只测每次新建缓冲区的成本，不与复制吞吐混合。
                buf := make([]byte, size)
                _ = buf
            }
        })
    }
}

拆开以后，结果含义清楚得多：一个基准评估复用后的复制效率，另一个基准评估按请求分配的成本。生产方案若使用 sync.Pool，还应单独测试池命中和并发争用，不能把单纯的 make 结果当成池化结论。

落地检查清单

• 所有子基准使用相同 payload、目标 Writer 和错误处理。
• payload 大于最大候选缓冲区，避免一次读写就完成。
• 确认源和目标不会通过 WriterTo/ReaderFrom 绕过 buffer。
• 缓冲区分配位置与真实生命周期一致：复用就放循环外，每次分配就另建基准。
• 调用 SetBytes 报告吞吐，调用 ReportAllocs 报告分配。
• 至少重复多轮，结合波动和内存预算选择，而不是只取一次最快值。
• 用真实磁盘、网络、TLS 与峰值并发对最终两个候选复测。

常见问题

为什么四种缓冲区的结果几乎一样？

先检查 CopyBuffer 是否走了 WriterTo 或 ReaderFrom 快速路径；再检查 payload 是否太小，导致不同容量都只需一次读写。

缓冲区应该在 B.Loop 外还是里面创建？

取决于问题。比较复用缓冲区的吞吐时放在外面；评估每次请求都分配缓冲区的总成本时放在里面，并最好拆成独立基准。

只比较 ns/op 可以吗？

不够。固定数据量时还要看 MB/s，并结合 B/op、allocs/op 和多轮波动，避免用少量时间差换来过高的并发内存占用。

为什么使用 B.Run 而不是在一个 B.Loop 里轮换大小？

每个 b.Run 都有独立的计时和指标，结果名称也清晰。若在同一循环里轮换大小，缓存状态、分支和工作量会混在一个平均值中，无法知道哪种容量真正更合适。

这套方法的核心不是找一个对所有场景都成立的“最佳缓冲区”，而是让每个候选在相同边界下被测量，再把单次吞吐放回并发内存、真实 I/O 和生命周期约束中做决策。