我們知道，Go 的語法比較簡潔。它並不提供類似 C 支援的 `while、do...while` 等迴圈控制語法，而僅保留了一種語句，即 for 迴圈。
```go
for i := 0; i < n; i++ {
    ... ...
}
```
但是，經典的三段式迴圈語句，需要獲取迭代物件的長度 n。鑑於此，為了更方便 Go 開發者對複合資料型別進行迭代，例如 `array、slice、channel、map`，Go 提供了 for 迴圈的變體，即 `for range` 迴圈。

### 副本複製問題

range 在帶來便利的同時，也給 Go 初學者帶來了一些麻煩。因為使用者需要明白一點：`for range` 中，參與迴圈表示式的只是物件的副本。
```go
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)
}
```
你認為這段程式碼會輸出以下結果嗎？
```go
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]
```
但是，實際輸出是
```go
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` 迴圈改寫成等效的虛擬碼形式。
```go
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 迴圈執行得慢？
```go
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 型別元素的陣列。讓我們看看基準測試的結果
```sh
$ 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 連結）。

讓我們關閉最佳化開關，再次執行壓力測試。
```sh
 $ 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 迴圈各自表現又會如何？
```go
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
 $ 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**

******************

#### 星球地址：https://t.zsxq.com/03MJM7YfI

#### **關注公眾號「程式設計師小喬」**

![程式設計師小喬](https://www.qsjob.fun/zb_users/upload/2022/07/202207041451541741109.jpg "程式設計師小喬")

Go 處理大陣列：使用 for range 還是 for 迴圈？

相關文章