当 golang 分配字符串到字节的转换时

Question

var testString = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
//var testString = "ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ"
func BenchmarkHashing900000000(b *testing.B){
    var bufByte = bytes.Buffer{}
    for i := 0; i < b.N ; i++{
        bufByte.WriteString(testString)
        Sum32(bufByte.Bytes())
        bufByte.Reset()
    }
}

func BenchmarkHashingWithNew900000000(b *testing.B){
    for i := 0; i < b.N ; i++{
        bytStr := []byte(testString)
        Sum32(bytStr)
    }
}

测试结果：

With  testString = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
BenchmarkHashing900000000-4         50000000            35.2 ns/op         0 B/op          0 allocs/op
BenchmarkHashingWithNew900000000-4  50000000            30.9 ns/op         0 B/op          0 allocs/op

With testString = "ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZ"
BenchmarkHashing900000000-4         30000000            46.6 ns/op         0 B/op          0 allocs/op
BenchmarkHashingWithNew900000000-4  20000000            73.0 ns/op        64 B/op          1 allocs/op

为什么在BenchmarkHashingWithNew900000000的情况下，字符串长时有分配，而字符串小时没有分配。
Sum32 : https://gowalker.org/github.com/spaolacci/murmur3
我正在使用 go1.6

Answer 1

您的基准测试正在观察 Golang 编译器（版本 1.8）的奇怪优化。

您可以在此处查看 Dmitry Dvyukov 的 PR

https://go-review.googlesource.com/c/go/+/3120

不幸的是，那是很久以前，当编译器是用 C 编写的时，我不确定在当前编译器中哪里可以找到优化。但我可以确认它仍然存在，而且 Dmitry 的 PR 描述是准确的。

如果您想要一套更清晰的自包含基准来证明这一点，我在这里有一个要点。

https://gist.github.com/fmstephe/f0eb393c4ec41940741376ab08cbdf7e

如果我们只看第二个基准BenchmarkHashingWithNew900000000，我们可以清楚地看到它“应该”分配的位置。

bytStr := []byte(testString)

此行必须将testString 的内容复制到一个新的[]byte 中。但是在这种情况下，编译器可以看到bytStr 在Sum32 返回后不再使用。因此它可以在堆栈上分配。但是，由于字符串可以任意大，分配的堆栈的限制设置为 32 个字节 string 或 []byte。

注意这个小技巧是值得的，因为如果你的基准字符串都很短，很容易让自己相信某些代码没有分配。

Answer 2

当您将内容写入byte.Buffer 时，它会根据需要分配内存。当您调用byte.Buffer.Reset 时，该内存不会被释放，而是保留以供以后重用。而您的代码正是这样做的。它将缓冲区标记为空，然后再次填充。

实际上， 有一些分配正在进行，但是当迭代 50000000 次时，它可以忽略不计。但是如果你将bufByte 的声明移动到for 循环中，你会得到一些分配。