Go|Go 性能提升tips--边界检查 Go性能提升tips--边界检查

1. 什么是边界检查？边界检查，英文名 Bounds Check Elimination，简称为 BCE。它是 Go 语言中防止数组、切片越界而导致内存不安全的检查手段。如果检查下标已经越界了，就会产生 Panic。
边界检查使得我们的代码能够安全地运行，但是另一方面，也使得我们的代码运行效率略微降低。
比如下面这段代码，会进行三次的边界检查

package mainfunc f(s []int) { _ = s[0]// 检查第一次 _ = s[1]// 检查第二次 _ = s[2]// 检查第三次 }func main() {}

你可能会好奇了，三次？我是怎么知道它要检查三次的。
实际上，你只要在编译的时候，加上参数即可，命令如下

go build -gcflags="-d=ssa/check_bce" demo.go # command-line-arguments ./demo.go:4:7: Found IsInBounds ./demo.go:5:7: Found IsInBounds ./demo.go:6:7: Found IsInBounds

2. 边界检查的条件？并不是所有的对数组、切片进行索引操作都需要边界检查。
比如下面这个示例，就不需要进行边界检查，因为编译器根据上下文已经得知，s 这个切片的长度是多少，你的终止索引是多少，立马就能判断到底有没有越界，因此是不需要再进行边界检查，因为在编译的时候就已经知道这个地方会不会 panic。

package mainfunc f1() { s := []int{1, 2, 3, 4} _ = s[:9] // 不需要边界检查} func main() {}

因此可以得出结论: 对于在编译阶段无法判断是否会越界的索引操作才会需要边界检查
比如这样子

package mainfunc f(s []int) { _ = s[:9]// 需要边界检查 } func main(){}

3. 边界检查的特殊案例 3.1 案例一
在如下示例代码中，由于索引 2 在最前面已经检查过会不会越界，因此聪明的编译器可以推断出后面的索引 0 和 1 不用再检查啦

package mainfunc f(s []int) { _ = s[2] // 检查一次 _ = s[1]// 不会检查 _ = s[0]// 不会检查 }func main() {}

3.2 案例二
在下面这个示例中，可以在逻辑上保证不会越界的代码，同样是不会进行越界检查的。

package mainfunc f(s []int) { for index, _ := range s { _ = s[index] _ = s[:index+1] _ = s[index:len(s)] } }func main(){}

3.3 案例三
在如下示例代码中，虽然数组的长度和容量可以确定，但是索引是通过 rand.Intn() 函数取得的随机数，在编译器看来这个索引值是不确定的，它有可能大于数组的长度，也有可能小于数组的长度。
因此第一次是需要进行检查的，有了第一次检查后，第二次索引从逻辑上就能推断，所以不会再进行边界检查。

package mainimport ( "math/rand" )func f(){ s := make([]int, 3, 3) index := rand.Intn(3) _ = s[:index]// 第一次检查 _ = s[index:]// 不会检查 }func main(){}

但如果把上面的代码稍微改一下，让切片的长度和容量变得不一样，结果又会变得不一样了。

package mainimport ( "math/rand" )func f(){ s := make([]int, 3, 5) index := rand.Intn(3) _ = s[:index]// 第一次检查 _ = s[index:]// 第二次检查 }func main(){}

只有当数组的长度和容量相等时， :index 成立，才能一定能推出 index: 也成立，这样的话，只要做一次检查即可
一旦数组的长度和容量不相等，那么 index 在编译器看来是有可能大于数组长度的，甚至大于数组的容量。
我们假设 index 取得的随机数为 4，那么它大于数组长度，此时 s[:index] 虽然可以成功，但是 s[index:] 是要失败的，因此第二次边界的检查是有必要的。
你可能会说， index 不是最大值为 3 吗？怎么可能是 4呢？
要知道编译器在编译的时候，并不知道 index 的最大值是 3 呢。
小结一下

当数组的长度和容量相等时，s[:index] 成立能够保证 s[index:] 也成立，因为只要检查一次即可
当数组的长度和容量不等时，s[:index] 成立不能保证 s[index:] 也成立，因为要检查两次才可以

3.4 案例四
有了上面的铺垫，再来看下面这个示例，由于数组是调用者传入的参数，所以编译器的编译的时候无法得知数组的长度和容量是否相等，因此只能保险一点，两个都检查。

package mainimport ( "math/rand" )func f(s []int, index int) { _ = s[:index] // 第一次检查 _ = s[index:] // 第二次检查 }func main(){}

如果把两个表达式的顺序反过来，就只要做一次检查就行了

package mainimport ( "math/rand" )func f(s []int, index int) { _ = s[index:] // 第一次检查 _ = s[:index] // 不用检查 }func main(){}

3.5. 主动消除边界检查
虽然编译器已经非常努力去消除一些应该消除的边界检查，但难免会有一些遗漏。
这就需要”警民合作”，对于那些编译器还未考虑到的场景，但开发者又极力追求程序的运行效率的，可以使用一些小技巧给出一些暗示，告诉编译器哪些地方可以不用做边界检查。
比如下面这个示例，从代码的逻辑上来说，是完全没有必要做边界检查的，但是编译器并没有那么智能，实际上每个for循环，它都要做一次边界的检查，非常的浪费性能。

package mainfunc f(is []int, bs []byte) { if len(is) >= 256 { for _, n := range bs { _ = is[n] // 每个循环都要边界检查 } } } func main(){}

可以试着在 for 循环前加上这么一句 is = is[:256] 来告诉编译器新 is 的长度为 256，最大索引值为 255，不会超过 byte 的最大值，因为 is[n] 从逻辑上来说是一定不会越界的。

package mainfunc f(is []int, bs []byte) { if len(is) >= 256 { is = is[:256] for _, n := range bs { _ = is[n] // 不需要做边界检查 } } } func main(){}

3.6 边界检查对性能的影响
一直在讨论边界检查对性能的影响，但是到底影响有多大呢？不妨以上面的例子做一个基准测试

package mainimport "testing"func f4(is []int, bs []byte) { if len(is) >= 256 { for _, n := range bs { _ = is[n] // 每个循环都要边界检查 } } }func f5(is []int, bs []byte) { if len(is) >= 256 { for _, n := range bs { is = is[:256] _ = is[n] // 每个循环都要边界检查 } } }func BenchmarkFunc_f4_test(b *testing.B) { s := make([]int, 1000, 10000000) bs := []byte{'b', 'a', 'c', 'd', 'e', 'g', 'h', 'j'} for i := 0; i < b.N; i++ { f4(s, bs) } }func BenchmarkFunc_f5_test(b *testing.B) { s := make([]int, 1000, 10000000) bs := []byte{'b', 'a', 'c', 'd', 'e', 'g', 'h', 'j'} for i := 0; i < b.N; i++ { f5(s, bs) } }

运行基准测试结果如下：

go test -bench=. -benchmem goos: linux goarch: amd64 pkg: Go_base/daily_test/bce_demo BenchmarkFunc_f4_test-81790742546.33 ns/op0 B/op0 allocs/op BenchmarkFunc_f5_test-82086927845.82 ns/op0 B/op0 allocs/op PASS okGo_base/daily_test/bce_demo3.253s

【Go|Go 性能提升tips--边界检查】如上结果，随着for循环次数的增加，其性能有了明显的差异，对于小的切片，数组操作时可能效果并不是很明显，但是如果涉及到数据比较大，或者性能比较严苛的地方，避免边界检查还是很有必要的。
四. 参考