Go 處理大數組：使用 for range 還是 for 循環？

我們知道，Go 的語法比較簡潔。它並不提供類似 C 支持的 while、do...while 等循環控制語法，而僅保留了一種語句，即 for 循環。

for i := 0; i < n; i++ {
    ... ...
}

但是，經典的三段式循環語句，需要獲取迭代對象的長度 n。鑑於此，爲了更方便 Go 開發者對複合數據類型進行迭代，例如 array、slice、channel、map，Go 提供了 for 循環的變體，即 for range 循環。

副本複製問題

range 在帶來便利的同時，也給 Go 初學者帶來了一些麻煩。因爲使用者需要明白一點：for range 中，參與循環表達式的只是對象的副本。

func main() {
    var a = [5]int{1, 2, 3, 4, 5}
    var r [5]int

    fmt.Println("original a =", a)

    for i, v := range a {
        if i == 0 {
            a[1] = 12
            a[2] = 13
        }
        r[i] = v
    }

    fmt.Println("after for range loop, r =", r)
    fmt.Println("after for range loop, a =", a)
}

你認爲這段代碼會輸出以下結果嗎？

original a = [1 2 3 4 5]
after for range loop, r = [1 12 13 4 5]
after for range loop, a = [1 12 13 4 5]

但是，實際輸出是

original a = [1 2 3 4 5]
after for range loop, r = [1 2 3 4 5]
after for range loop, a = [1 12 13 4 5]

爲什麼會這樣？原因是參與 for range 循環是 range 表達式的副本。也就是說，在上面的例子中，實際上參與循環的是 a 的副本，而不是真正的 a。

爲了讓大家更容易理解，我們把上面例子中的 for range 循環改寫成等效的僞代碼形式。

for i, v := range ac { //ac is a value copy of a
    if i == 0 {
        a[1] = 12
        a[2] = 13
    }
    r[i] = v
}

ac 是 Go 臨時分配的連續字節序列，與 a 根本不是同一塊內存空間。因此，無論 a 如何修改，它參與循環的副本 ac 仍然保持原始值，因此從 ac 中取出的 v 也依然是 a 的原始值，而不是修改後的值。

那麼，問題來了，既然 for range 使用的是副本數據，那 for range 會比經典的 for 循環消耗更多的資源並且性能更差嗎？

性能對比

基於副本複製問題，我們先使用基準示例來驗證一下：對於大型數組，for range 是否一定比經典的 for 循環運行得慢？

package main

import "testing"

func BenchmarkClassicForLoopIntArray(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]int
 for i := 0; i < b.N; i++ {
  for j := 0; j < len(arr); j++ {
   arr[j] = j
  }
 }
}

func BenchmarkForRangeIntArray(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]int
 for i := 0; i < b.N; i++ {
  for j, v := range arr {
   arr[j] = j
   _ = v
  }
 }
}

在這個例子中，我們使用 for 循環和 for range 分別遍歷一個包含 10 萬個 int 類型元素的數組。讓我們看看基準測試的結果

$ go test -bench . forRange1_test.go 
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
BenchmarkClassicForLoopIntArray-8          47404             25486 ns/op               0 B/op          0 allocs/op
BenchmarkForRangeIntArray-8                37142             31691 ns/op               0 B/op          0 allocs/op
PASS
ok      command-line-arguments  2.978s

從輸出結果可以看出，for range 的確會稍劣於 for 循環，當然這其中包含了編譯器級別優化的結果（通常是靜態單賦值，或者 SSA 鏈接）。

讓我們關閉優化開關，再次運行壓力測試。

 $ go test -c -gcflags '-N -l' . -o forRange1.test
 $ ./forRange1.test -test.bench .
 goos: darwin
goarch: amd64
pkg: workspace/example/forRange
cpu: Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
BenchmarkClassicForLoopIntArray-8           6734            175319 ns/op               0 B/op          0 allocs/op
BenchmarkForRangeIntArray-8                 5178            242977 ns/op               0 B/op          0 allocs/op
PASS

當沒有編譯器優化時，兩種循環的性能都明顯下降， for range 下降得更爲明顯，性能也更加比經典 for 循環差。

遍歷結構體數組

上述性能測試中，我們的遍歷對象類型是 int 值的數組，如果我們將 int 元素改爲結構體會怎麼樣？for 和 for range 循環各自表現又會如何？

package main

import "testing"

type U5 struct {
 a, b, c, d, e int
}
type U4 struct {
 a, b, c, d int
}
type U3 struct {
 b, c, d int
}
type U2 struct {
 c, d int
}
type U1 struct {
 d int
}

func BenchmarkClassicForLoopLargeStructArrayU5(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U5
 for i := 0; i < b.N; i++ {
  for j := 0; j < len(arr)-1; j++ {
   arr[j].d = j
  }
 }
}
func BenchmarkClassicForLoopLargeStructArrayU4(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U4
 for i := 0; i < b.N; i++ {
  for j := 0; j < len(arr)-1; j++ {
   arr[j].d = j
  }
 }
}
func BenchmarkClassicForLoopLargeStructArrayU3(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U3
 for i := 0; i < b.N; i++ {
  for j := 0; j < len(arr)-1; j++ {
   arr[j].d = j
  }
 }
}
func BenchmarkClassicForLoopLargeStructArrayU2(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U2
 for i := 0; i < b.N; i++ {
  for j := 0; j < len(arr)-1; j++ {
   arr[j].d = j
  }
 }
}

func BenchmarkClassicForLoopLargeStructArrayU1(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U1
 for i := 0; i < b.N; i++ {
  for j := 0; j < len(arr)-1; j++ {
   arr[j].d = j
  }
 }
}

func BenchmarkForRangeLargeStructArrayU5(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U5
 for i := 0; i < b.N; i++ {
  for j, v := range arr {
   arr[j].d = j
   _ = v
  }
 }
}
func BenchmarkForRangeLargeStructArrayU4(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U4
 for i := 0; i < b.N; i++ {
  for j, v := range arr {
   arr[j].d = j
   _ = v
  }
 }
}

func BenchmarkForRangeLargeStructArrayU3(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U3
 for i := 0; i < b.N; i++ {
  for j, v := range arr {
   arr[j].d = j
   _ = v
  }
 }
}
func BenchmarkForRangeLargeStructArrayU2(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U2
 for i := 0; i < b.N; i++ {
  for j, v := range arr {
   arr[j].d = j
   _ = v
  }
 }
}
func BenchmarkForRangeLargeStructArrayU1(b *testing.B) {
 b.ReportAllocs()
 var arr [100000]U1
 for i := 0; i < b.N; i++ {
  for j, v := range arr {
   arr[j].d = j
   _ = v
  }
 }
}

在這個例子中，我們定義了 5 種類型的結構體：U1~U5，它們的區別在於包含的 int 類型字段的數量。

性能測試結果如下

 $ go test -bench . forRange2_test.go
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
BenchmarkClassicForLoopLargeStructArrayU5-8        44540             26227 ns/op               0 B/op          0 allocs/op
BenchmarkClassicForLoopLargeStructArrayU4-8        45906             26312 ns/op               0 B/op          0 allocs/op
BenchmarkClassicForLoopLargeStructArrayU3-8        43315             27400 ns/op               0 B/op          0 allocs/op
BenchmarkClassicForLoopLargeStructArrayU2-8        44605             26313 ns/op               0 B/op          0 allocs/op
BenchmarkClassicForLoopLargeStructArrayU1-8        45752             26110 ns/op               0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU5-8               3072            388651 ns/op               0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU4-8               4605            261329 ns/op               0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU3-8               5857            182565 ns/op               0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU2-8              10000            108391 ns/op               0 B/op          0 allocs/op
BenchmarkForRangeLargeStructArrayU1-8              36333             32346 ns/op               0 B/op          0 allocs/op
PASS
ok      command-line-arguments  16.160s

我們看到一個現象：不管是什麼類型的結構體元素數組，經典的 for 循環遍歷的性能比較一致，但是 for range 的遍歷性能會隨着結構字段數量的增加而降低。

帶着疑惑，發現了一個與這個問題相關的 issue：cmd/compile: optimize large structs：https://github.com/golang/go/issues/24416。這個 issue 大致是說：如果一個結構體類型有超過一定數量的字段（或一些其他條件），就會將該類型視爲 unSSAable。如果 SSA 不可行，那麼就無法通過 SSA 優化，這也是造成上述基準測試結果的重要原因。

結論

對於遍歷大數組而言， for 循環能比 for range 循環更高效與穩定，這一點在數組元素爲結構體類型更加明顯。

另外，由於在 Go 中切片的底層都是通過數組來存儲數據，儘管有 for range 的副本複製問題，但是切片副本指向的底層數組與原切片是一致的。這意味着，當我們將數組通過切片代替後，不管是通過 for range 或者 for 循環均能得到一致的穩定的遍歷性能。

本文部分內容翻譯整理自：Handling Large Arrays in Golang: Should You Use For Range or For Loop? https://betterprogramming.pub/handling-large-arrays-in-golang-should-you-use-for-range-or-for-loop-9995a02fd316

機器鈴砍菜刀

歡迎添加小菜刀微信

加入 Golang 分享羣學習交流！

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/TsRJWpbrMbN6jVISAvY-HQ