介紹一些開發中常用的slice關聯的效能最佳化手段。鑑於golang編譯器本身捉雞的最佳化能力，最佳化的成本就得分攤在開發者自己的頭上了。
這篇文章會介紹的最佳化手段是下面這幾樣：
- 建立slice時預分配記憶體
- 操作slice前預分配記憶體
- slice表示式中合理設定cap值
- 新增多個零值元素的最佳化
- 迴圈展開
- 避免for-range複製資料帶來的損耗
- 邊界檢查消除
- 並行處理slice
- 複用slice的記憶體
- 高效刪除多個元素
- 減輕GC掃描壓力
這篇文章不會討論快取命中率和SIMD，我知道這兩樣也和slice的效能相關，但前者我認為是合格的開發者必須要了解的，網上優秀的教程也很多不需要我再贅述，後者除非效能瓶頸真的在資料吞吐量上否則一般不應該納入考慮範圍尤其在go語言裡，所以這兩個主題本文不會介紹。
最後開篇之前我還想提醒一下，效能瓶頸要靠測試和profile來定位，效能最佳化方案的收益和開銷也需要效能測試來衡量，切記不可生搬硬套。
本文比較長，所以我建議可以挑自己感興趣的內容看，有時間再通讀。
本文索引
- 建立slice時預分配記憶體
- 操作slice前預分配記憶體
- slice表示式中合理設定cap值
- 向slice新增多個零值元素的最佳化
- 迴圈展開
- 避免for-ranges複製資料帶來的損耗
- 避免複製
- 遍歷字串的時候避免轉換帶來的開銷
- BCE邊界檢查消除
- 並行處理slice
- 複用
- 高效刪除多個元素
- 刪除所有元素
- 刪除頭部或尾部的元素
- 刪除在中間位置的元素
- 減輕GC掃描壓力
- 總結
建立slice時預分配記憶體
預分配記憶體是最常見的最佳化手段，我會分為建立時和使用中兩部分來講解如何進行最佳化。
提前為要建立的slice分配足夠的記憶體，可以消除後續新增元素時擴容產生的效能損耗。
具體做法如下：
s1 := make([]T, 0, 預分配的元素個數)
// 另一種不太常見的預分配手段，此時元素個數必須是常量
var arr [元素個數]T
s2 := arr[:]
很簡單的程式碼，效能測試我就不做了。
前面說到新增元素時擴容產生的效能損耗，這個損耗分為兩方面，一是擴容需要重新計算slice的cap，尤其是1.19之後採用更緩和的分配策略後計算量是有所增加的，另一方面在於重新分配記憶體，如果沒能原地擴容的話還需要重新分配一塊記憶體把資料移動過去，再釋放原先的記憶體，新增的元素越多遇到這種情況的機率越大，這是相當大的開銷。
另外slice採用的擴容策略有時候會造成浪費，比如下面這樣：
func main() {
var a []int
for i := 0; i < 2048; i++ {
a = append(a, i)
}
fmt.Println(cap(a)) // go1.22: 2560
}
可以看到，我們新增了2048個元素，但go最後給我們分配了2560個元素的記憶體，浪費了將近500個。
不過預分配不是萬金油，有限定了的適用場景：
適用場景：
- 明確知道slice裡會有多少個元素的場景
- 元素的個數雖然不確定，但大致在
[x, y]的區間內，這時候可以選擇設定預分配大小為y+N（N取決於誤差範圍，預分配大量記憶體之後再觸發擴容的代價非常高昂，所以算好誤差範圍寧可少量浪費也要避免再次擴容），當然x和y之間的差不能太大，像1和1000這種很明顯是不應該進行預分配的，主要的判斷依據是最壞情況下的記憶體浪費率。
除了上面兩種情況，我不建議使用預分配，因為分配記憶體本身是要付出效能的代價的，不是上面兩種場景時預分配都會不可避免的產生大量浪費，這些浪費帶來的效能代價很可能會超過擴容的代價。
預分配記憶體還有另一個好處：如果分配的大小是常量或者常量表示式，則有機會被逃逸分析認定為大小合適分配在棧上，從而使效能更進一步提升。這也是編譯器實現的，具體的程式碼如下：
// https://github.com/golang/go/blob/master/src/cmd/compile/internal/walk/builtin.go#L412
// walkMakeSlice walks an OMAKESLICE node.
func walkMakeSlice(n *ir.MakeExpr, init *ir.Nodes) ir.Node {
l := n.Len
r := n.Cap
if r == nil {
r = safeExpr(l, init)
l = r
}
t := n.Type()
if t.Elem().NotInHeap() {
base.Errorf("%v can't be allocated in Go; it is incomplete (or unallocatable)", t.Elem())
}
if n.Esc() == ir.EscNone {
if why := escape.HeapAllocReason(n); why != "" {
base.Fatalf("%v has EscNone, but %v", n, why)
}
// 檢查i是否是常量
i := typecheck.IndexConst(r)
if i < 0 {
base.Fatalf("walkExpr: invalid index %v", r)
}
// 檢查透過後建立slice臨時變數，分配在棧上
}
// 逃逸了，這時候會生成呼叫runtime.makeslice的程式碼
// runtime.makeslice用mallocgc從堆分配記憶體
}
棧上分配記憶體速度更快，而且對gc的壓力也更小一些，但物件會在哪被分配並不是我們能控制的，我們能做的也只有創造讓物件分配在棧上的機會僅此而已。
操作slice前預分配記憶體
從slices包進入標準庫開始，操作現有的slice時也能預分配記憶體了。
當然之前也可以，不過得繞些彎路，有興趣可以去看下slices.Grow是怎麼做的。
透過簡單的測試來看看效果：
func BenchmarkAppend(b *testing.B) {
for i := 0; i < b.N; i++ {
s := []int{1, 2, 3, 4, 5}
for j := 0; j < 1024; j++ {
s = append(s, j)
}
}
}
func BenchmarkAppendWithGrow(b *testing.B) {
for i := 0; i < b.N; i++ {
s := []int{1, 2, 3, 4, 5}
s = slices.Grow(s, 1024)
for j := 0; j < 1024; j++ {
s = append(s, j)
}
}
}
這是結果，用benchstat進行了比較：
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Append-8 4.149µ ± 3% 1.922µ ± 5% -53.69% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
Append-8 19.547Ki ± 0% 9.250Ki ± 0% -52.68% (p=0.000 n=10)
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
Append-8 8.000 ± 0% 1.000 ± 0% -87.50% (p=0.000 n=10)
不僅速度快了一倍，記憶體也節約了50%，而且相比未用Grow的程式碼，最佳化過後的程式碼只需要一次記憶體分配。
效能提升的原因和上一節的完全一樣：避免了多次擴容帶來的開銷。
同時節約記憶體的好處也和上一節一樣是存在的：
func main() {
s1 := make([]int, 10, 50) // 注意已經有一定的預分配了
for i := 0; i < 1024; i++ {
s1 = append(s1, i)
}
fmt.Println(cap(s1)) // 1280
s2 := make([]int, 10, 50)
s2 = slices.Grow(s3, 1024)
for i := 0; i < 1024; i++ {
s2 = append(s2, i)
}
fmt.Println(cap(s2)) // 1184
}
如例子所示，前者的記憶體利用率是80%，而後者是86.5%，Grow雖然也是利用append的機制來擴容，但它可以更充分得利用記憶體，避免了浪費。
也和上一節一樣，使用前的預分配的適用場景也只有兩個：
- 明確知道會往slice裡追加多少個元素的場景
- 追加的元素的個數雖然不確定，但大致在
[x, y]的區間內，這時候可以選擇設定預分配大小為y+N（和上面一樣，N取決於誤差範圍）。
另外如果是拼接多個slice，最好使用slices.Concat，因為它內部會用Grow預分配足夠的記憶體，比直接用append快一些。這也算本節所述最佳化手段的一個活得例子。
slice表示式中合理設定cap值
在比較新的go版本里slice表示式是可以有第三個引數的，即cap的值，形式類似：slice[start:end:capEnd]。
注意我用了capEnd而不是cap，因為這個引數不是cap的長度，而是指新的slice最大可以訪問到原陣列或者slice的（索引-1）的元素。舉個例子：slice[1:2:3]，這個表示式建立了一個新的切片，長度為2-1即1，可以訪問到原切片的索引3-1即2的元素，因此新切片可以訪問的元素實際上有index 1和index 2兩個，cap為2。
為啥要加這個引數呢？因為可以限制切片訪問的範圍，避免意外地改變資料。
當然那麼沒有第三個引數的時候cap是怎麼處理的呢？當然是相當於cap(old slice) - start了。
這和效能最佳化有什麼關係呢？看個例子：
func noop(s []int) int {
return s[1] + s[2]
}
func BenchmarkSlice(b *testing.B) {
slice := []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
for i := 0; i < b.N; i++ {
noop(slice[1:5])
}
}
func BenchmarkSliceWithEqualCap(b *testing.B) {
slice := []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10}
for i := 0; i < b.N; i++ {
noop(slice[1:5:5])
}
}
測試結果：
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
BenchmarkSlice-8 1000000000 0.3263 ns/op 0 B/op 0 allocs/op
BenchmarkSliceWithEqualCap-8 1000000000 0.3015 ns/op 0 B/op 0 allocs/op
如果用benchstat進行比較，平均來說使用slice[1:5:5]的程式碼要快3%左右。
事實上這裡有一個go的小最佳化，當切片表示式裡第二個引數和第三個引數一樣的時候，cap可以不用額外計算，直接取之前算出來的length就行了。這會少幾次記憶體訪問和一個減法運算。
不信可以看看編譯器的程式碼：
// slice computes the slice v[i:j:k] and returns ptr, len, and cap of result.
// i,j,k may be nil, in which case they are set to their default value.
// v may be a slice, string or pointer to an array.
func (s *state) slice(v, i, j, k *ssa.Value, bounded bool) (p, l, c *ssa.Value) {
t := v.Type
var ptr, len, cap *ssa.Value
switch {
case t.IsSlice():
ptr = s.newValue1(ssa.OpSlicePtr, types.NewPtr(t.Elem()), v)
// 計算slice的len和cap
len = s.newValue1(ssa.OpSliceLen, types.Types[types.TINT], v)
cap = s.newValue1(ssa.OpSliceCap, types.Types[types.TINT], v)
case t.IsString():
// 省略，這裡不重要
case t.IsPtr():
// 同上省略
default:
s.Fatalf("bad type in slice %v\n", t)
}
// 如果是s[:j:k]，i會預設設定為0
if i == nil {
i = s.constInt(types.Types[types.TINT], 0)
}
// 如果是s[i:]，則j設定為len(s)
if j == nil {
j = len
}
three := true
// 如果是s[i:j:], 則k設定為cap(s)
if k == nil {
three = false
k = cap
}
// 對i，j和k進行邊界檢查
// 先理解成加減乘除的運算子就行
subOp := s.ssaOp(ir.OSUB, types.Types[types.TINT])
mulOp := s.ssaOp(ir.OMUL, types.Types[types.TINT])
andOp := s.ssaOp(ir.OAND, types.Types[types.TINT])
// Calculate the length (rlen) and capacity (rcap) of the new slice.
// For strings the capacity of the result is unimportant. However,
// we use rcap to test if we've generated a zero-length slice.
// Use length of strings for that.
rlen := s.newValue2(subOp, types.Types[types.TINT], j, i)
rcap := rlen
if j != k && !t.IsString() {
rcap = s.newValue2(subOp, types.Types[types.TINT], k, i)
}
// 計算slice的記憶體從那裡開始的，在這不重要忽略
return rptr, rlen, rcap
}
整體沒什麼難的，所有切片表示式最終都會走到這個函式，這個函式會生產相應的opcode，這個opcode會過一次相對簡單的最佳化，然後編譯器根據這些的opcode生成真正的可以執行的程式。
重點在於if j != k && !t.IsString()這句，分支裡那句rcap = s.newValue2(subOp, types.Types[types.TINT], k, i)翻譯成普通的go程式碼的話相當於rcap = k - i，k的值怎麼計算的在前面的註釋裡有寫。這意味著切片表示式的二三兩個引數如果值一樣且不是string，那麼會直接複用length而不需要額外的計算了。題外話，這裡雖然我用了“計算”這個詞，但實際是rcap和rlen還都只是表示式，真正的結果是要在程式執行的時候才能計算得到的，有興趣的話可以自己研究一下go的編譯器。
正是因為這個小小的最佳化帶來了細微的效能提升。
當然，這些只是程式碼生成中的細節，只有這個原因的話我通常不會推薦這樣的做法。
所以更重要的是在於前面提到的安全性：限制切片訪問的範圍，避免意外地改變資料。在此基礎上不僅不會有效能下降還有小幅的上升，算是錦上添花。
適用場景：當切片的cap和length理論上長度應該相等時，最好都明確地進行設定，比如：slice[i : j+2 : j+2]這樣。
上面這個場景估計能佔到一半左右，當然還有很多不符合上述要求的場景，所以不要生搬硬套，一切以效能測試為準。
具體可以看這個pr是怎麼做的：https://github.com/golang/go/pull/64835
向slice新增多個零值元素的最佳化
往slice裡新增“0”也有些小竅門，看看下面的測試：
func BenchmarkAppendZeros1(b *testing.B) {
for i := 0; i < b.N; i++ {
slice := []int{}
slice = append(slice, []int{0, 0, 0, 0, 0}...)
}
}
// 最佳化版本
func BenchmarkAppendZeros2(b *testing.B) {
for i := 0; i < b.N; i++ {
slice := []int{}
slice = append(slice, make([]int, 5)...)
}
}
測試結果：
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
AppendZeros-8 31.79n ± 2% 30.04n ± 2% -5.50% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
AppendZeros-8 48.00 ± 0% 48.00 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
AppendZeros-8 1.000 ± 0% 1.000 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
一行程式碼，在記憶體用量沒有變化的情況下效能提升了5%。
秘密依然在編譯器裡。
不管是append(s1, s2...)還是append(s1, make([]T, length)...)，編譯器都有特殊的處理。
前者的流程是這樣的：
- 建立s2（如果s2是個slice的字面量的話）
- 檢查s1的cap，不夠的情況下要擴容
- 將s2的內容copy到s1裡
使用make時的流程是這樣的：
- 檢查s1的cap，不夠的情況下要擴容
- 對length長度的s1的空閒記憶體做memclr（將記憶體中的值全設定為0）
程式碼在這裡：https://github.com/golang/go/blob/master/src/cmd/compile/internal/walk/assign.go#L647
效能提升的秘密在於：不用建立臨時的slice，以及memclr做的事比copy更少也更簡單所以更快。
而且顯然append(s1, make([]T, length)...)的可讀性也是更好的，可謂一舉兩得。
適用場景：需要往slice新增連續的零值的時候。
迴圈展開
用迴圈處理slice裡的資料也是常見的需求，相比下一節會提到的for-range，普通迴圈訪問資料的形式可以更加靈活，而且也不會受1.22改變range執行時行為的影響。
說到迴圈相關的最佳化，迴圈展開是繞不開的話題。顧名思義，就是把本來要迭代n次的迴圈，改成每輪迭代裡處理比原先多m倍的資料，這樣總的迭代次數會降為n/m + 1次。
這樣為啥會更快呢？其中一點是可以少很多次迴圈跳轉和邊界條件的更新及比較。另一點是現代 CPU 都有一個叫做指令流水線的東西，它可以同時執行多條指令，如果它們之間沒有資料依賴（後一項資料依賴前一項作為輸入）的話，展開迴圈後意味著有機會讓一部分指令並行從而提高吞吐量。
然鵝通常這不是程式設計師該關心的事，因為怎麼展開迴圈，什麼時候應該展開什麼時候不應（迴圈展開後會影響到當前函式能否被內聯等）都是一個有著良好的最佳化過程的編譯器該做的。
你問go呢？那是自然沒有的。在執行時效能和語言表現力之間，go選擇了編譯速度。編譯得確實快，然而最佳化上就要眼前一黑了。
所以只能自己寫了：
func loop(s []int) int {
sum := 0
for i := 0; i < len(s); i++ {
sum += s[i]
}
return sum
}
func unroll4(s []int) int {
sum := 0
for i := 0; i < len(s); i += 4 {
sum += s[i]
sum += s[i+1]
sum += s[i+2]
sum += s[i+3]
}
return sum
}
func BenchmarkLoop(b *testing.B) {
s := []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 35, 26, 27, 28, 29, 30, 31}
for i := 0; i < b.N; i++ {
loop(s)
}
}
func BenchmarkUnroll4(b *testing.B) {
s := []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 35, 26, 27, 28, 29, 30, 31}
for i := 0; i < b.N; i++ {
unroll4(s)
}
}
func BenchmarkUnroll8(b *testing.B) {
s := []int{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 35, 26, 27, 28, 29, 30, 31}
for i := 0; i < b.N; i++ {
unroll8(s)
}
}
測試使用32個int的slice，首先和一個迴圈裡處理四個資料的對比：
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Unroll-8 9.718n ± 3% 3.196n ± 2% -67.11% (p=0.000 n=10)
│ old.txt │ new.txt │
│ B/op │ B/op vs base │
Unroll-8 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
│ old.txt │ new.txt │
│ allocs/op │ allocs/op vs base │
Unroll-8 0.000 ± 0% 0.000 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
提升了將近67%，相當之大了。然後我們和一次處理8個資料的比比看：
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Unroll-8 9.718n ± 3% 2.104n ± 1% -78.34% (p=0.000 n=10)
這次提升了78%，相比一次只處理四個，處理8個的方法快了30%。
我這為了方便只處理了總資料量是每輪迭代處理資料數量整數倍的情況，非整數倍的時候需要藉助“達夫裝置”，在go裡實現起來比較麻煩，所以偷個懶。不過鑑於迴圈展開帶來的提升非常之大，如果確定迴圈處理slice的程式碼是效能瓶頸，不妨可以實現一下試試效果。
適用場景：slice的長度需要維持在固定值上，且長度需要時每輪迭代處理資料量的整數倍。
需要仔細效能測試的場景：如果單次迴圈需要處理的內容很多程式碼很長，那麼展開的效果很可能是沒有那麼好的甚至起反效果，因為過多的程式碼會影響當前函式和當前程式碼呼叫的函式是否被內聯以及區域性變數的逃逸分析，前者會使函式呼叫的開銷被放大同時干擾分支預測和流水線執行導致效能下降，後者則會導致不必要的逃逸同時降低效能和增加堆記憶體用量。
另外每次迭代處理多少個元素也沒必要拘泥於4或者2的倍數什麼的，理論上不管一次處理幾個都會有顯著的效能提升，實際測試也是如此，一次性處理3、5或者7個的效果和4或者8個時差不多，總體來說一次處理的越多提升越明顯。但如果展開的太過火就會發展成為上面說的需要嚴格測試的場景了。所以我建議展開處理的數量最好別超過8個。
避免for-ranges複製資料帶來的損耗
普通的迴圈結構提供了靈活的訪問方式，但要是遍歷slice的話我想大部分人的首選應該是for-ranges結構吧。
這一節要說的東西與其叫效能最佳化，到不如說應該是“如何避開for-ranges”的效能陷阱才對。
先說說陷阱在哪。
陷阱其實有兩個，一個基本能避開，另一個得看情況才行。我們先從能完全避開的開始。
避免複製
第一個坑在於range遍歷slice的時候，會把待遍歷的資料複製一份到迴圈變數裡，而且從1.22開始range的迴圈遍歷每次迭代都會建立出一個新的例項，如果沒注意到這點的話不僅效能下降還會使記憶體壓力急劇升高。我們要做的就是避免不必要的複製帶來的開銷。
作為例子，我們用包含8個int64和1個string的結構體填充slice然後對比複製和不復制時的效能：
type Data struct {
a, b, c, d, e, f, g, h int64
text string
}
func generateData(n int) []Data {
ret := make([]Data, 0, n)
for i := range int64(n) {
ret = append(ret, Data{
a: i,
b: i + 1,
c: i + 2,
d: i + 3,
e: i + 4,
f: i + 5,
g: i + 6,
h: i + 7,
text: "測試",
})
}
return ret
}
// 會導致額外複製資料的例子
func BenchmarkRanges1(b *testing.B) {
data := generateData(100)
b.ResetTimer()
for i := 0; i < b.N; i++ {
tmp := int64(0)
for _, v := range data { // 資料被複制給迴圈變數v
tmp -= v.a - v.h
}
}
}
// 避免了複製的例子
func BenchmarkRanges2(b *testing.B) {
data := generateData(100)
b.ResetTimer()
for i := 0; i < b.N; i++ {
tmp := int64(0)
for i := range data { // 注意這兩行
v := &data[i]
tmp -= v.a - v.h
}
}
}
結果：
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Ranges-8 33.51n ± 2% 32.63n ± 1% -2.41% (p=0.000 n=10)
使用指標或者直接透過索引訪問可以避免複製，如結果所示，結構體越大效能的差異就越明顯。此外新版本的go修改了range的語義，從以前會複用迴圈變數變成了每輪迴圈都建立新的迴圈變數，這會使一部分存在複製開銷的for-range迴圈變得更慢。
適用場景：需要遍歷每個元素，遍歷的slice裡的單項資料比較大且明確不需要遍歷的資料被額外複製給迴圈變數的時候。
遍歷字串的時候避免轉換帶來的開銷
字串可能有點偏題了，但我們要說的這點也勉強和slice有關。
這個坑在於，range遍歷字串的時候會把字串的內容轉換成一個個rune，這一步會帶來開銷，尤其是字串裡只有ascii字元的時候。
寫個簡單例子看看效能損耗有多少：
func checkByte(s string) bool {
for _, b := range []byte(s) {
if b == '\n' {
return true
}
}
return false
}
func checkRune(s string) bool {
for _, r := range s {
if r == '\n' {
return true
}
}
return false
}
func BenchmarkRanges1(b *testing.B) {
s := "abcdefghijklmnopqrstuvwxyz1234567890."
for i := 0; i < b.N; i++ {
checkRune(s)
}
}
func BenchmarkRanges2(b *testing.B) {
s := "abcdefghijklmnopqrstuvwxyz1234567890."
for i := 0; i < b.N; i++ {
checkByte(s)
}
}
這是結果：
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
│ old.txt │ new.txt │
│ sec/op │ sec/op vs base │
Ranges-8 36.07n ± 2% 23.95n ± 1% -33.61% (p=0.000 n=10)
把string轉換成[]byte再遍歷的效能居然提升了1/3。換句話說如果你沒注意到這個坑，那麼就要白白丟失這麼多效能了。
而且將string轉換成[]byte是不需要額外分配新的記憶體的，可以直接複用string內部的資料，當然前提是不會修改轉換後的slice，在這裡我們把這個slice直接交給了range，它不會修改slice，所以轉換的開銷被省去了。
這個最佳化是從1.6開始的，有興趣可以看看編譯器的程式碼：https://github.com/golang/go/blob/master/src/cmd/compile/internal/walk/convert.go#L316 （看程式碼其實還有別的針對這種轉換的最佳化，比如字串比較短的時候轉換出來的[]byte會分配在棧上）
當然，如果你要處理ASCII以外的字元，比如中文漢字，那麼這個最佳化就行不通了。
適用場景：需要遍歷處理的字串裡的字元都在ASCII編碼的範圍內，比如只有換行符英文半形數字和半形標點的字串。
BCE邊界檢查消除
邊界檢查是指在訪問slice元素、使用slice表示式、make建立slice等場景下檢查引數的值是否超過最大限制以及是否會越界訪問記憶體。這些檢查是編譯器根據編譯時獲得的資訊新增到對應位置上的，檢查的程式碼會在執行時被執行。
這個特性對於程式的安全非常重要。
那麼是否只要是有上述表示式的地方就會導致邊界檢查呢？答案是不，因為邊界檢查需要取slice的長度或者cap然後進行比較，檢查失敗的時候會panic，整個造成有些花時間而且對分支預測不是很友好，總體上每個訪問slice元素的表示式都新增檢查會拖垮效能。
因此邊界檢查消除就順理成章出現了——一些場景下明顯index不可能有越界問題，那麼檢查就是完全不必要的。
如何檢視編譯器在哪裡插入了檢查呢？可以用下面這個命令：go build -gcflags='-d=ssa/check_bce' main.go。
以上一節的unroll4為例子：
$ go build -gcflags='-d=ssa/check_bce' main.go
# command-line-arguments
./main.go:8:11: Found IsInBounds
./main.go:9:11: Found IsInBounds
./main.go:10:11: Found IsInBounds
./main.go:11:11: Found IsInBounds
目前你會看到兩種輸出IsInBounds和IsSliceInBounds。兩者都是插入邊界檢測的證明，檢查的內容差不多，只有微小的差別，有興趣可以看ssa怎麼生成兩者程式碼的：https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/rewriteAMD64.go#L25798
那麼這些檢查怎麼消除呢？具體來說可以分為好幾種情況，但隨著編譯器的發展肯定會有不少變化，所以我不準備一一列舉。
既然不列舉，那肯定有大致通用的規則：如果使用index訪問slice前的表示式裡可以推算出當前index值不會越界，那麼檢查就能消除。
舉幾個例子：
s1 := make([]T, 10)
s1[9] // 常數索引值編譯時就能判斷是否越界，所以不需要插入執行時的檢測。
_ = s1[i&6] // 索引的值肯定在0-6之間，檢查被消除
var s2 []int
_ = s2[:i] // 檢查
_ = s2[:i] // 重複訪問，消除邊界檢查
_ = s2[:i+1] // 檢查
_ = s2[:i+1] // 重複的表示式，檢查過了所以檢查被消除
func f(s []int) int {
if len(s) < 3 {
panic("error")
}
return s[1] + s[2] // 前面的if保證了這兩個訪問一定不會越界，所以檢查可以消除
}
// 一種透過臨時變數避免多次邊界檢測的常用作法
func f2(s []int) int {
tmp := s[:4:4] // 這裡會邊界檢查。這裡還利用了前面說的合理設定slice表示式的cap避免額外開銷
a := tmp[2] // tmp那裡的檢查保證了這裡不會越界，因此不會再檢查
b := tmp[3] // 同上
return a+b
}
我沒列出所有例子，想看的可以去這裡。
當然有一些隱藏的不能消除檢查的場景：
func f(s []int, i int) {
if i < len(s) {
fmt.Println(s[i]) // 消除不了，因為i是有符號整數，可能會小於0
}
}
func f(s []int, i int) {
if 0 < i && i < len(s) {
fmt.Println(s[i+2]) // 消除不了，因為i是有符號整數，i+2萬一發生溢位，索引值會因為繞回而變成負數
}
}
有了這些知識，前面的unroll4有四次邊界檢查，實際上用不著這麼多，因此可以改成下面這樣：
func unroll4(s []int) int {
sum := 0
for i := 0; i < len(s); i += 4 {
tmp := s[i : i+4 : i+4] // 只有這裡會檢查一次
sum += tmp[0]
sum += tmp[1]
sum += tmp[2]
sum += tmp[3]
}
return sum
}
這麼做實際上還是會檢查一次，能不能完全消除呢？
func unroll4(s []int) int {
sum := 0
for len(s) >= 4 {
sum += s[0]
sum += s[1]
sum += s[2]
sum += s[3]
s = s[4:] // 忽略掉已經處理過的四個元素，而且因為len(s) >= 4，所以這裡也不需要檢查
}
return sum
}
這樣檢查就完全消除了，但多了一次slice的賦值。
然而我這的例子實在是太簡單了，效能測試顯示邊界檢查消除並沒有帶來效能提升，完全消除了檢查的那個例子反而因為額外的slice賦值操作帶來了輕微的效能下降（和消除到只剩一次檢查的比較）。
如果想要看效果更明顯的例子，可以參考這篇部落格。
適用場景：能有效利用len(slice)的結果的地方可以嘗試BCE。
其他場合需要透過效能測試來判斷是否有提升以及提升的幅度。像這樣既不像設定slice表示式cap值那樣增強安全性又不像用make批次新增空值那樣增加可讀性的改動，個人認為除非真的是效能瓶頸而且沒有其他最佳化手段，否則提升低於5%的話建議不要做這類改動。
並行處理slice
前面說到了迴圈展開，基於這一手段更進一步的最佳化就是並行處理了。這裡的並行不是指SIMD，而是依賴goroutine實現的並行。
能並行的前提是slice元素的處理不會互相依賴，比如s[1]的處理依賴於s[0]的處理結果這樣的。
在能確定slice的處理可以並行後，就可以寫一些並行程式碼了，比如並行求和：
func Sum(s []int64) int64 {
// 假設s的長度是4000
var sum atomic.Int64
var wg sync.WaitGroup
// 每個goroutine處理800個
for i := 0; i < len(s); i += 800 {
wg.Add(1)
go func(ss []int) {
defer wg.Done()
var ret int64
for j := range ss {
ret += ss[j]
}
sum.Add(ret)
}(s[i: i+800])
}
wg.Wait()
return sum.Load()
}
很簡單的程式碼。和迴圈展開一樣，需要額外料理數量不夠一次處理的剩餘的元素。
另外協程的建立銷燬以及資料的同步都是比較耗時的，如果slice裡元素很少的話並行處理反而得不償失。
適用場景：slice裡元素很多、對元素的處理可以並行互不干擾，還有重要的一點，golang程式可以使用超過一個cpu核心保證程式碼真正可以“並行”執行。
複用
複用slice是個常見的套路，其中複用[]byte是最為常見的。
複用可以利用sync.Pool，也可以像下面這樣：
buf := make([]byte, 1024)
for {
read(buf)
...
// reuse
buf = buf[:0]
}
其中buf = buf[:0]使得slice的cap不變，length清零，這樣就可以複用slice的記憶體了。使用sync.Pool時也需要這樣使slice的長度為零。
此外使用sync.Pool時還要注意slice的尺寸不能太大，否則同樣會增加gc負擔。一般來說超過1M大小的slice是不建議存進去的，當然還得結合專案需求和效能測試才能決定尺寸的上限。
適用場景：你的slice記憶體可以反覆被使用（最好是能直接重用連清理都可以不做的那種，清理會讓最佳化效果打點折扣）並且多次建立slice確實成為了效能瓶頸時。
高效刪除多個元素
刪除元素也是常見需求，這裡我們也要分三種情況來討論。
這三種情況都包含在標準庫的slices.Delete裡了，所以比起自己寫我更推薦你用標準庫。因此本節沒有適用場景這一環境，但每一小節針對一些特殊場景給出了相應的建議。
刪除所有元素
如果刪除元素後也不打算複用slice了，直接設定為nil就行。
如果還要複用記憶體，利用我們在複用那節裡提到的s := s[:0]就行，不過光這樣還不夠，為了防止記憶體洩漏還得把刪除的元素全部清零，在1.21前我們只能這麼做：
func deleteSlice[T any, S ~[]T](s S) S {
var zero T
for i := range s {
s[i] = zero
}
return s[:0]
}
1.21之後我們有了clear內建函式，程式碼可以大幅簡化：
func deleteSlice[T any, S ~[]T](s S) S {
clear(s)
return s[:0]
}
兩種寫法的效能是一樣的，因為go專門對for-range迴圈寫入零值做了最佳化，效果和直接用clear一樣：
func BenchmarkClear(b *testing.B) {
for i := 0; i < b.N; i++ {
var a = [...]uint64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1}
clear(a[:])
}
}
func BenchmarkForRange(b *testing.B) {
for i := 0; i < b.N; i++ {
var a = [...]uint64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1}
for j := range a {
a[j] = 0
}
}
}
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
BenchmarkClear-8 1000000000 0.2588 ns/op 0 B/op 0 allocs/op
BenchmarkForRange-8 1000000000 0.2608 ns/op 0 B/op 0 allocs/op
但是如果迴圈的形式不是for-range，那麼就吃不到這個最佳化了：
func BenchmarkClear(b *testing.B) {
for i := 0; i < b.N; i++ {
var a = [...]uint64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1}
clear(a[:])
}
}
func BenchmarkForLoop(b *testing.B) {
for i := 0; i < b.N; i++ {
var a = [...]uint64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1}
for j := 0; j < 20; j++ {
a[j] = 0
}
}
}
goos: windows
goarch: amd64
cpu: Intel(R) Core(TM) i5-10200H CPU @ 2.40GHz
BenchmarkClear-8 1000000000 0.2613 ns/op 0 B/op 0 allocs/op
BenchmarkForLoop-8 173418799 7.088 ns/op 0 B/op 0 allocs/op
速度相差一個數量級。對“迴圈寫零”最佳化有興趣的可以在這看到是這麼實現的：arrayclear。這個最佳化對map也有效果。
我們可以簡單對比下置空為nil和clear的效能：
func BenchmarkDeleteWithClear(b *testing.B) {
for i := 0; i < b.N; i++ {
a := []uint64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1}
clear(a)
a = a[:0]
}
}
func BenchmarkDeleteWithSetNil(b *testing.B) {
for i := 0; i < b.N; i++ {
a := []uint64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1}
a = a[:] // 防止編譯器認為a沒有被使用
a = nil
}
}
從結果來看只是刪除操作的話沒有太大區別：
BenchmarkDeleteWithClear-8 1000000000 0.2592 ns/op 0 B/op 0 allocs/op
BenchmarkDeleteWithSetNil-8 1000000000 0.2631 ns/op 0 B/op 0 allocs/op
所以選用哪種方式主要取決於你後續是否還要複用slice的記憶體，需要複用就用clear，否則直接設為nil。
刪除頭部或尾部的元素
刪除尾部元素是最簡單的，最快的方法只有s = s[:index]這一種。注意別忘了要用clear清零被刪除的部分。
這個方法唯一的缺點是被刪除的部分的記憶體不會釋放，通常這沒有壞處而且能在新新增元素時複用這些記憶體，但如果你不會再複用這些記憶體並且對浪費很敏感，那隻能分配一個新slice然後把要留下的元素複製過去了，但要注意這麼做的話會慢很多而且在刪除的過程中要消費更多記憶體（因為新舊兩個slice得同時存在）。
刪除頭部元素的選擇就比較多了，常見的有兩種（我們需要保持元素之間的相對順序）：s = s[index+1:]或者s = append(s[:0], s[index+1:]...)。
前者是新建一個slice，底層陣列起始為止指向原先slice的index+1處，注意雖然底層陣列被複用了，但cap實際上是減小的，而且被刪除部分的記憶體沒有機會再被複用了。這種方法需要在刪除前先把元素清零。
後一種則不會建立新的slice，它把index+1開始的元素平移到了slice的頭部，這樣也是刪除了頭部的元素（被覆蓋掉了）。使用這種方案不需要主動清零元素，你要是不放心移動後尾部剩下的空間也可以選擇使用clear但一般不建議。
理論上前者真正地浪費了記憶體但效能更好，不過效能始終要用benchmark來證明：
func BenchmarkClearWithReSlice(b *testing.B) {
for i := 0; i < b.N; i++ {
a := []uint64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1}
// 刪除頭部7個元素
clear(a[:7])
a = a[7:]
}
}
func BenchmarkClearWithAppend(b *testing.B) {
for i := 0; i < b.N; i++ {
a := []uint64{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1}
a = append(a[:0], a[7:]...)
}
}
測試結果顯示確實第一種方法快：
BenchmarkClearWithReSlice-8 1000000000 0.2636 ns/op 0 B/op 0 allocs/op
BenchmarkClearWithAppend-8 100000000 10.82 ns/op 0 B/op 0 allocs/op
Append慢了一個數量級，即使memmove已經得到了相當多的最佳化，在記憶體裡移動資料還是很慢的。
在實際應用中應該根據記憶體利用效率和執行速度綜合考慮選擇合適的方案。
刪除在中間位置的元素
刪除中間部分的元素還要保持相對順序，能用的辦法就只有移動刪除部分後面的元素到前面進行覆蓋這一種辦法：
s := append(s[:index], s[index+n:]...)
這個方法也不需要主動clear被刪除元素，因為它們都被覆蓋掉了。利用append而不是for迴圈除了前面說的for迴圈最佳化差之外還有程式碼更簡潔和能利用memmove這兩個優勢。
因為方法唯一沒啥參照物，所以效能就不測試了。
減輕GC掃描壓力
簡單的說，儘量不要在slice裡存放大量的指標或者包含指標的結構體。指標越多gc在掃描物件時需要做的工作就越多，最後會導致效能下降。
更具體的解釋和效能測試可以看這篇。
適用場景：無特殊需求且元素大小不是特別大的，存值優於存指標。
作為代價，如果選擇了存值，得小心額外的複製導致的開銷。
總結
按個人經驗來看，使用頻率最高的幾個最佳化手段依次是預分配記憶體、避免for-ranges踩坑、slice複用、迴圈展開。從提升來看這幾個也是效果最明顯的。
編譯器的最佳化不夠給力的話就只能自己想辦法用這些最佳化技巧了。
有時候也可以利用逃逸分析規則來做最佳化，但正如這篇文章所說，絕大多數情況下你都不應該考慮逃逸分析。
還有另外一條路：給go編譯器共享程式碼提升編譯產物的效能。雖然阻力會很大，但我還是相信有大佬一定能做到的。這也是我為什麼會把編譯器怎麼做最佳化的程式碼貼出來，拋磚引玉嘛。
還有最重要的一點：效能問題不管是定位還是最佳化，都必須以效能測試為依據，切記不可光靠“經驗”和沒有事實依據支撐的“推論”。
最後我希望這篇文章能成為大家最佳化效能時的趁手工具，而不是面試時背的八股文。