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

【问题标题】：Why does Go have runtime overhead for range loops over an array?为什么 Go 对数组上的范围循环有运行时开销？
【发布时间】：2018-08-23 15:39:13
【问题描述】：

我希望对数组元素进行范围迭代不会带来任何运行时开销，但它似乎比原始数组访问慢 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 等其他语言中？这似乎违反了零成本抽象，并且在性能敏感的上下文中相当烦人，如果没有快速的替代方法来手动写出数组访问。

【问题讨论】：

“我希望对数组元素进行范围迭代不会带来任何运行时开销，”您的期望是不合理的。
@peterSO 我想知道像 Python 这样的语言是否也有这样的开销
感谢您的回复，很高兴知道。考虑到显着的加速，当可迭代对象在编译时已知大小时，编译器在原始数组访问中替换它是否比我认为的更困难？
小心：总结实际上并没有发生。如果你return the sum 那么它实际上也是计算出来的。
您将展开循环与常规循环进行比较。这是一个众所周知的优化。您至少应该检查程序集输出。展开的循环可以很好地使用向量指令进行优化。所有这些都与任何语言相关。这可能更多地与特定的编译器实现有关。如果 go 编译器在某些方面缺乏，你应该提出问题。

标签： go optimization iteration

【解决方案1】：

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

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

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

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

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

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

我检查了其他几种语言（如 java、python 和 rust）中的 for 循环性能，它们都比 go 的实现慢。

【讨论】：