为什么 Go 对数组上的范围循环有运行时开销?

Question

我希望对数组的元素进行范围迭代不会带来任何运行时开销，但它似乎比原始数组访问慢 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

如果它是一个在编译时长度未知的切片而不是数组，这可能是有意义的，在这种情况下，运行时代码必须涉及带有边界检查的循环。但是，对于在编译时已知大小的数组，编译器可以只将范围迭代换成手动访问，因为开销很大。

注意：我还尝试了更惯用的元素范围循环：

sum := 0
for _, el := range nums {
sum += el
}

这甚至更慢(4 ns/op(。

一个附带的问题：这种开销是否存在于其他语言(如 Rust(中？这似乎违反了零成本抽象，如果在性能敏感的上下文中，如果没有手动写出数组访问的快速替代方案，这相当烦人。

Answer 1

首先，观察for循环中实际发生的情况：

for i := range sums {
// your code goes here
}

在每次迭代中，您都在增加 i，这显然是一个开销。

为什么编译器不将其替换为您可能问的每次迭代的原始访问？这将是完全不合理的，因为您的二进制大小会急剧增加。

考虑在正常范围内循环。它将值存储在另一个变量中，然后在其他地方访问它。

实际上，go的for循环是许多语言中最快的，我不确定它的确切原因，但您可以在这篇文章中获得更多信息。

我已经检查了其他几种语言(如java，python和rust(的for循环性能，所有这些语言都比go的实现慢。