我希望对数组元素进行范围迭代不会带来任何运行时开销,但它似乎比原始数组访问慢 8 倍:
func BenchmarkSumRange(b *testing.B) {
nums := [5]int{0, 1, 2, 3, 4}
for n := 0; n < b.N; n++ {
sum := 0
for i, _ := range nums {
sum += nums[i]
}
}
}
func BenchmarkSumManual(b *testing.B) {
nums := [5]int{0, 1, 2, 3, 4}
for n := 0; n < b.N; n++ {
sum := 0
sum += nums[0]
sum += nums[1]
sum += nums[2]
sum += nums[3]
sum += nums[4]
}
}
基准输出:
BenchmarkSumRange-8 1000000000 2.18 ns/op
BenchmarkSumManual-8 2000000000 0.28 ns/op
如果它是一个长度在编译时未知的 slice 而不是一个数组,这可能是有意义的,在这种情况下,运行时代码必须涉及一个带有边界检查的循环。但对于在编译时已知大小的数组,考虑到开销很大,编译器可以将范围迭代替换为手动访问。
注意:我还尝试了更惯用的元素范围循环:
sum := 0
for _, el := range nums {
sum += el
}
这甚至更慢(4 ns/op)。
附带问题:这种开销是否存在于其他语言(如 Rust)中?这似乎违反了零成本抽象,如果没有快速的替代方法来手动写出数组访问,那么在对性能敏感的上下文中相当烦人。
最佳答案
首先,观察 for
循环中实际发生了什么:
for i := range sums {
// your code goes here
}
在每次迭代中,您都会递增 i,这显然是一种开销。
对于您可能会问的每次迭代,为什么编译器不将其替换为原始访问?这是完全不合理的,因为您的二进制文件大小会急剧增加。
考虑在正常范围内循环。它将值存储在另一个变量中,然后在其他地方访问它。
实际上 go 的 for
循环是许多语言中最快的,我不确定它的确切原因,但您可以在此 post 中获得更多信息。 .
我检查了 java、python 和 rust 等其他几种语言的 for
循环性能,它们都比 go 的实现慢。
关于go - 为什么 Go 对数组的范围循环有运行时开销?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/51989507/