为什么固定大小的切片分配起来并不比可变大小的 bytes.Buffer 更便宜？

Question

这是我的测试代码：

package app

import (
    "bytes"
    "testing"
)

const ALLOC_SIZE = 64 * 1024

func BenchmarkFunc1(b *testing.B) {
    for i := 0; i < b.N; i++ {
        v := make([]byte, ALLOC_SIZE)
        fill(v, '1', 0, ALLOC_SIZE)
    }
}

func BenchmarkFunc2(b *testing.B) {
    for i := 0; i < b.N; i++ {
        b := new(bytes.Buffer)
        b.Grow(ALLOC_SIZE)
        fill(b.Bytes(), '2', 0, ALLOC_SIZE)
    }
}

func fill(slice []byte, val byte, start, end int) {
    for i := start; i < end; i++ {
        slice = append(slice, val)
    }
}

结果：

at 19:05:47 ❯ go test -bench . -benchmem -gcflags=-m
# app [app.test]
./main_test.go:25:6: can inline fill
./main_test.go:10:6: can inline BenchmarkFunc1
./main_test.go:13:7: inlining call to fill
./main_test.go:20:9: inlining call to bytes.(*Buffer).Grow
./main_test.go:21:15: inlining call to bytes.(*Buffer).Bytes
./main_test.go:21:7: inlining call to fill
./main_test.go:10:21: b does not escape
./main_test.go:12:12: make([]byte, ALLOC_SIZE) escapes to heap
./main_test.go:20:9: BenchmarkFunc2 ignoring self-assignment in bytes.b.buf = bytes.b.buf[:bytes.m·3]
./main_test.go:17:21: b does not escape
./main_test.go:19:11: new(bytes.Buffer) does not escape
./main_test.go:25:11: slice does not escape
# app.test
/var/folders/45/vh6dxx396d590hxtz7_9_smmhqf0sq/T/go-build1328509211/b001/_testmain.go:35:6: can inline init.0
/var/folders/45/vh6dxx396d590hxtz7_9_smmhqf0sq/T/go-build1328509211/b001/_testmain.go:43:24: inlining call to testing.MainStart
/var/folders/45/vh6dxx396d590hxtz7_9_smmhqf0sq/T/go-build1328509211/b001/_testmain.go:43:42: testdeps.TestDeps{} escapes to heap
/var/folders/45/vh6dxx396d590hxtz7_9_smmhqf0sq/T/go-build1328509211/b001/_testmain.go:43:24: &testing.M{...} escapes to heap
goos: darwin
goarch: amd64
pkg: app
cpu: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
BenchmarkFunc1-8            8565            118348 ns/op          393217 B/op          4 allocs/op
BenchmarkFunc2-8           23332             53043 ns/op           65536 B/op          1 allocs/op
PASS
ok      app     2.902s

我的假设是使用由 make 创建的固定大小的切片比 bytes.Buffer 便宜得多，因为编译器可能能够知道在编译时需要分配的内存大小 -时间。使用 bytes.Buffer 看起来有点像运行时的东西。然而，结果并不是我所期望的那样。

有什么解释吗？

Answer 1

您混淆了切片的容量和长度。

v := make([]byte, ALLOC_SIZE)

v 现在是一个长度为 64k，容量为 64k 的切片。将任何内容附加到此切片会强制 Go 将支持数组复制到一个新的更大的数组中。

b := new(bytes.Buffer)
b.Grow(ALLOC_SIZE)
v := b.Bytes()

这里，v是一个长度为0，容量为64k的slice。您可以将 64k 字节附加到此切片而无需任何重新分配，因为它最初是空的，但 64k 支持数组已准备好使用。

总而言之，您是在比较容量已满的切片与容量相同的空切片。

为了进行公平比较，更改您的第一个基准以分配一个空切片：

func BenchmarkFunc1(b *testing.B) {
    for i := 0; i < b.N; i++ {
        v := make([]byte, 0, ALLOC_SIZE) // note the three argument form
        fill(v, '1', 0, ALLOC_SIZE)
    }
}

goos: linux
goarch: amd64
pkg: foo
cpu: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz
BenchmarkFunc1-8           23540             51990 ns/op           65536 B/op          1 allocs/op
BenchmarkFunc2-8           24939             45096 ns/op           65536 B/op          1 allocs/op

切片、数组、长度和容量之间的关系在https://blog.golang.org/slices-intro

中有非常详细的解释

为什么固定大小的切片分配起来并不比可变大小的 bytes.Buffer 更便宜？

Why fixed-sized slices are not cheaper to allocate than variable-sized bytes.Buffer?

performance

memory-management

heap-memory

go