這篇文章不會討論緩存命中率和SIMD，我知道這兩樣也和slice的性能相關(guān)，但前者我認為是合格的開發(fā)者必須要了解的，網(wǎng)上優(yōu)秀的教程也很多不需要我再贅述，后者除非性能瓶頸真的在數(shù)據(jù)吞吐量上否則一般不應(yīng)該納入考慮范圍尤其在go語言里，所以這兩個主題本文不會介紹。

最后開篇之前我還想提醒一下，性能瓶頸要靠測試和profile來定位，性能優(yōu)化方案的收益和開銷也需要性能測試來衡量，切記不可生搬硬套。

創(chuàng)建slice時預(yù)分配內(nèi)存

預(yù)分配內(nèi)存是最常見的優(yōu)化手段，我會分為創(chuàng)建時和使用中兩部分來講解如何進行優(yōu)化。

提前為要創(chuàng)建的slice分配足夠的內(nèi)存，可以消除后續(xù)添加元素時擴容產(chǎn)生的性能損耗。

具體做法如下：

s1 := make([]T, 0, 預(yù)分配的元素個數(shù))
 
// 另一種不太常見的預(yù)分配手段，此時元素個數(shù)必須是常量
var arr [元素個數(shù)]T
s2 := arr[:]

很簡單的代碼，性能測試我就不做了。

前面說到添加元素時擴容產(chǎn)生的性能損耗，這個損耗分為兩方面，一是擴容需要重新計算slice的cap，尤其是1.19之后采用更緩和的分配策略后計算量是有所增加的，另一方面在于重新分配內(nèi)存，如果沒能原地擴容的話還需要重新分配一塊內(nèi)存把數(shù)據(jù)移動過去，再釋放原先的內(nèi)存，添加的元素越多遇到這種情況的概率越大，這是相當大的開銷。

另外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個元素的內(nèi)存，浪費了將近500個。

不過預(yù)分配不是萬金油，有限定了的適用場景：

適用場景：

• 明確知道slice里會有多少個元素的場景
• 元素的個數(shù)雖然不確定，但大致在[x, y]的區(qū)間內(nèi)，這時候可以選擇設(shè)置預(yù)分配大小為y+N（N取決于誤差范圍，預(yù)分配大量內(nèi)存之后再觸發(fā)擴容的代價非常高昂，所以算好誤差范圍寧可少量浪費也要避免再次擴容），當然x和y之間的差不能太大，像1和1000這種很明顯是不應(yīng)該進行預(yù)分配的，主要的判斷依據(jù)是最壞情況下的內(nèi)存浪費率。

除了上面兩種情況，我不建議使用預(yù)分配，因為分配內(nèi)存本身是要付出性能的代價的，不是上面兩種場景時預(yù)分配都會不可避免的產(chǎn)生大量浪費，這些浪費帶來的性能代價很可能會超過擴容的代價。

預(yù)分配內(nèi)存還有另一個好處：如果分配的大小是常量或者常量表達式，則有機會被逃逸分析認定為大小合適分配在棧上，從而使性能更進一步提升。這也是編譯器實現(xiàn)的，具體的代碼如下：

// 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)
		}
 
		// 檢查通過后創(chuàng)建slice臨時變量，分配在棧上
	}
 
	// 逃逸了，這時候會生成調(diào)用runtime.makeslice的代碼
    // runtime.makeslice用mallocgc從堆分配內(nèi)存
}

棧上分配內(nèi)存速度更快，而且對gc的壓力也更小一些，但對象會在哪被分配并不是我們能控制的，我們能做的也只有創(chuàng)造讓對象分配在棧上的機會僅此而已。

操作slice前預(yù)分配內(nèi)存

從slices包進入標準庫開始，操作現(xiàn)有的slice時也能預(yù)分配內(nèi)存了。

當然之前也可以，不過得繞些彎路，有興趣可以去看下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)
		}
	}
}

這是結(jié)果，用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)

不僅速度快了一倍，內(nèi)存也節(jié)約了50%，而且相比未用Grow的代碼，優(yōu)化過后的代碼只需要一次內(nèi)存分配。

性能提升的原因和上一節(jié)的完全一樣：避免了多次擴容帶來的開銷。

同時節(jié)約內(nèi)存的好處也和上一節(jié)一樣是存在的：

func main() {
	s1 := make([]int, 10, 50) // 注意已經(jīng)有一定的預(yù)分配了
	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
}

如例子所示，前者的內(nèi)存利用率是80%，而后者是86.5%，Grow雖然也是利用append的機制來擴容，但它可以更充分得利用內(nèi)存，避免了浪費。

也和上一節(jié)一樣，使用前的預(yù)分配的適用場景也只有兩個：

• 明確知道會往slice里追加多少個元素的場景
• 追加的元素的個數(shù)雖然不確定，但大致在[x, y]的區(qū)間內(nèi)，這時候可以選擇設(shè)置預(yù)分配大小為y+N（和上面一樣，N取決于誤差范圍）。

另外如果是拼接多個slice，最好使用slices.Concat，因為它內(nèi)部會用Grow預(yù)分配足夠的內(nèi)存，比直接用append快一些。這也算本節(jié)所述優(yōu)化手段的一個活得例子。

slice表達式中合理設(shè)置cap值

在比較新的go版本里slice表達式是可以有第三個參數(shù)的，即cap的值，形式類似：slice[start:end:capEnd]。

注意我用了capEnd而不是cap，因為這個參數(shù)不是cap的長度，而是指新的slice最大可以訪問到原數(shù)組或者slice的（索引-1）的元素。舉個例子：slice[1:2:3]，這個表達式創(chuàng)建了一個新的切片，長度為2-1即1，可以訪問到原切片的索引3-1即2的元素，因此新切片可以訪問的元素實際上有index 1和index 2兩個，cap為2。

為啥要加這個參數(shù)呢？因為可以限制切片訪問的范圍，避免意外地改變數(shù)據(jù)。

當然那么沒有第三個參數(shù)的時候cap是怎么處理的呢？當然是相當于cap(old slice) - start了。

這和性能優(yōu)化有什么關(guān)系呢？看個例子：

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])
	}
}

測試結(jié)果：

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的小優(yōu)化，當切片表達式里第二個參數(shù)和第三個參數(shù)一樣的時候，cap可以不用額外計算，直接取之前算出來的length就行了。這會少幾次內(nèi)存訪問和一個減法運算。

不信可以看看編譯器的代碼：

// 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會默認設(shè)置為0
	if i == nil {
		i = s.constInt(types.Types[types.TINT], 0)
	}
    // 如果是s[i:]，則j設(shè)置為len(s)
	if j == nil {
		j = len
	}
	three := true
    // 如果是s[i:j:], 則k設(shè)置為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的內(nèi)存從那里開始的，在這不重要忽略
 
	return rptr, rlen, rcap
}

整體沒什么難的，所有切片表達式最終都會走到這個函數(shù)，這個函數(shù)會生產(chǎn)相應(yīng)的opcode，這個opcode會過一次相對簡單的優(yōu)化，然后編譯器根據(jù)這些的opcode生成真正的可以運行的程序。

重點在于if j != k && !t.IsString()這句，分支里那句rcap = s.newValue2(subOp, types.Types[types.TINT], k, i)翻譯成普通的go代碼的話相當于rcap = k - i，k的值怎么計算的在前面的注釋里有寫。這意味著切片表達式的二三兩個參數(shù)如果值一樣且不是string，那么會直接復(fù)用length而不需要額外的計算了。題外話，這里雖然我用了“計算”這個詞，但實際是rcap和rlen還都只是表達式，真正的結(jié)果是要在程序運行的時候才能計算得到的，有興趣的話可以自己研究一下go的編譯器。

正是因為這個小小的優(yōu)化帶來了細微的性能提升。

當然，這些只是代碼生成中的細節(jié)，只有這個原因的話我通常不會推薦這樣的做法。

所以更重要的是在于前面提到的安全性：限制切片訪問的范圍，避免意外地改變數(shù)據(jù)。在此基礎(chǔ)上不僅不會有性能下降還有小幅的上升，算是錦上添花。

適用場景：當切片的cap和length理論上長度應(yīng)該相等時，最好都明確地進行設(shè)置，比如：slice[i : j+2 : j+2]這樣。

上面這個場景估計能占到一半左右，當然還有很多不符合上述要求的場景，所以不要生搬硬套，一切以性能測試為準。

具體可以看這個pr是怎么做的：https://github.com/golang/go/pull/64835

向slice添加多個零值元素的優(yōu)化

往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}...)
	}
}
 
// 優(yōu)化版本
func BenchmarkAppendZeros2(b *testing.B) {
	for i := 0; i < b.N; i++ {
		slice := []int{}
		slice = append(slice, make([]int, 5)...)
	}
}

測試結(jié)果：

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

一行代碼，在內(nèi)存用量沒有變化的情況下性能提升了5%。

秘密依然在編譯器里。

不管是append(s1, s2...)還是append(s1, make([]T, length)...)，編譯器都有特殊的處理。

前者的流程是這樣的：

• 創(chuàng)建s2（如果s2是個slice的字面量的話）
• 檢查s1的cap，不夠的情況下要擴容
• 將s2的內(nèi)容copy到s1里

使用make時的流程是這樣的：

• 檢查s1的cap，不夠的情況下要擴容
• 對length長度的s1的空閑內(nèi)存做memclr（將內(nèi)存中的值全設(shè)置為0）

代碼在這里：https://github.com/golang/go/blob/master/src/cmd/compile/internal/walk/assign.go#L647

性能提升的秘密在于：不用創(chuàng)建臨時的slice，以及memclr做的事比copy更少也更簡單所以更快。

而且顯然append(s1, make([]T, length)...)的可讀性也是更好的，可謂一舉兩得。

適用場景：需要往slice添加連續(xù)的零值的時候。

循環(huán)展開

用循環(huán)處理slice里的數(shù)據(jù)也是常見的需求，相比下一節(jié)會提到的for-range，普通循環(huán)訪問數(shù)據(jù)的形式可以更加靈活，而且也不會受1.22改變range運行時行為的影響。

說到循環(huán)相關(guān)的優(yōu)化，循環(huán)展開是繞不開的話題。顧名思義，就是把本來要迭代n次的循環(huán)，改成每輪迭代里處理比原先多m倍的數(shù)據(jù)，這樣總的迭代次數(shù)會降為n/m + 1次。

這樣為啥會更快呢？其中一點是可以少很多次循環(huán)跳轉(zhuǎn)和邊界條件的更新及比較。另一點是現(xiàn)代 CPU 都有一個叫做指令流水線的東西，它可以同時運行多條指令，如果它們之間沒有數(shù)據(jù)依賴（后一項數(shù)據(jù)依賴前一項作為輸入）的話，展開循環(huán)后意味著有機會讓一部分指令并行從而提高吞吐量。

然鵝通常這不是程序員該關(guān)心的事，因為怎么展開循環(huán)，什么時候應(yīng)該展開什么時候不應(yīng)（循環(huán)展開后會影響到當前函數(shù)能否被內(nèi)聯(lián)等）都是一個有著良好的優(yōu)化過程的編譯器該做的。

你問go呢？那是自然沒有的。在運行時性能和語言表現(xiàn)力之間，go選擇了編譯速度。編譯得確實快，然而優(yōu)化上就要眼前一黑了。

所以只能自己寫了：

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，首先和一個循環(huán)里處理四個數(shù)據(jù)的對比：

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個數(shù)據(jù)的比比看：

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%。

我這為了方便只處理了總數(shù)據(jù)量是每輪迭代處理數(shù)據(jù)數(shù)量整數(shù)倍的情況，非整數(shù)倍的時候需要借助“達夫設(shè)備”，在go里實現(xiàn)起來比較麻煩，所以偷個懶。不過鑒于循環(huán)展開帶來的提升非常之大，如果確定循環(huán)處理slice的代碼是性能瓶頸，不妨可以實現(xiàn)一下試試效果。

適用場景：slice的長度需要維持在固定值上，且長度需要時每輪迭代處理數(shù)據(jù)量的整數(shù)倍。

需要仔細性能測試的場景：如果單次循環(huán)需要處理的內(nèi)容很多代碼很長，那么展開的效果很可能是沒有那么好的甚至起反效果，因為過多的代碼會影響當前函數(shù)和當前代碼調(diào)用的函數(shù)是否被內(nèi)聯(lián)以及局部變量的逃逸分析，前者會使函數(shù)調(diào)用的開銷被放大同時干擾分支預(yù)測和流水線執(zhí)行導(dǎo)致性能下降，后者則會導(dǎo)致不必要的逃逸同時降低性能和增加堆內(nèi)存用量。

另外每次迭代處理多少個元素也沒必要拘泥于4或者2的倍數(shù)什么的，理論上不管一次處理幾個都會有顯著的性能提升，實際測試也是如此，一次性處理3、5或者7個的效果和4或者8個時差不多，總體來說一次處理的越多提升越明顯。但如果展開的太過火就會發(fā)展成為上面說的需要嚴格測試的場景了。所以我建議展開處理的數(shù)量最好別超過8個。

避免for-ranges復(fù)制數(shù)據(jù)帶來的損耗

普通的循環(huán)結(jié)構(gòu)提供了靈活的訪問方式，但要是遍歷slice的話我想大部分人的首選應(yīng)該是for-ranges結(jié)構(gòu)吧。

這一節(jié)要說的東西與其叫性能優(yōu)化，到不如說應(yīng)該是“如何避開for-ranges”的性能陷阱才對。

先說說陷阱在哪。

陷阱其實有兩個，一個基本能避開，另一個得看情況才行。我們先從能完全避開的開始。

避免復(fù)制

第一個坑在于range遍歷slice的時候，會把待遍歷的數(shù)據(jù)復(fù)制一份到循環(huán)變量里，而且從1.22開始range的循環(huán)遍歷每次迭代都會創(chuàng)建出一個新的實例，如果沒注意到這點的話不僅性能下降還會使內(nèi)存壓力急劇升高。我們要做的就是避免不必要的復(fù)制帶來的開銷。

作為例子，我們用包含8個int64和1個string的結(jié)構(gòu)體填充slice然后對比復(fù)制和不復(fù)制時的性能：

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
}
 
// 會導(dǎo)致額外復(fù)制數(shù)據(jù)的例子
func BenchmarkRanges1(b *testing.B) {
	data := generateData(100)
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		tmp := int64(0)
		for _, v := range data { // 數(shù)據(jù)被復(fù)制給循環(huán)變量v
			tmp -= v.a - v.h
		}
	}
}
 
// 避免了復(fù)制的例子
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
		}
	}
}

結(jié)果：

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)

使用指針或者直接通過索引訪問可以避免復(fù)制，如結(jié)果所示，結(jié)構(gòu)體越大性能的差異就越明顯。此外新版本的go修改了range的語義，從以前會復(fù)用循環(huán)變量變成了每輪循環(huán)都創(chuàng)建新的循環(huán)變量，這會使一部分存在復(fù)制開銷的for-range循環(huán)變得更慢。

適用場景：需要遍歷每個元素，遍歷的slice里的單項數(shù)據(jù)比較大且明確不需要遍歷的數(shù)據(jù)被額外復(fù)制給循環(huán)變量的時候。

遍歷字符串的時候避免轉(zhuǎn)換帶來的開銷

字符串可能有點偏題了，但我們要說的這點也勉強和slice有關(guān)。

這個坑在于，range遍歷字符串的時候會把字符串的內(nèi)容轉(zhuǎn)換成一個個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)
	}
}

這是結(jié)果：

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轉(zhuǎn)換成[]byte再遍歷的性能居然提升了1/3。換句話說如果你沒注意到這個坑，那么就要白白丟失這么多性能了。

而且將string轉(zhuǎn)換成[]byte是不需要額外分配新的內(nèi)存的，可以直接復(fù)用string內(nèi)部的數(shù)據(jù)，當然前提是不會修改轉(zhuǎn)換后的slice，在這里我們把這個slice直接交給了range，它不會修改slice，所以轉(zhuǎn)換的開銷被省去了。

這個優(yōu)化是從1.6開始的，有興趣可以看看編譯器的代碼：https://github.com/golang/go/blob/master/src/cmd/compile/internal/walk/convert.go#L316 （看代碼其實還有別的針對這種轉(zhuǎn)換的優(yōu)化，比如字符串比較短的時候轉(zhuǎn)換出來的[]byte會分配在棧上）

當然，如果你要處理ASCII以外的字符，比如中文漢字，那么這個優(yōu)化就行不通了。

適用場景：需要遍歷處理的字符串里的字符都在ASCII編碼的范圍內(nèi)，比如只有換行符英文半角數(shù)字和半角標點的字符串。

BCE邊界檢查消除

邊界檢查是指在訪問slice元素、使用slice表達式、make創(chuàng)建slice等場景下檢查參數(shù)的值是否超過最大限制以及是否會越界訪問內(nèi)存。這些檢查是編譯器根據(jù)編譯時獲得的信息添加到對應(yīng)位置上的，檢查的代碼會在運行時被運行。

這個特性對于程序的安全非常重要。

那么是否只要是有上述表達式的地方就會導(dǎo)致邊界檢查呢？答案是不，因為邊界檢查需要取slice的長度或者cap然后進行比較，檢查失敗的時候會panic，整個造成有些花時間而且對分支預(yù)測不是很友好，總體上每個訪問slice元素的表達式都添加檢查會拖垮性能。

因此邊界檢查消除就順理成章出現(xiàn)了——一些場景下明顯index不可能有越界問題，那么檢查就是完全不必要的。

如何查看編譯器在哪里插入了檢查呢？可以用下面這個命令：go build -gcflags='-d=ssa/check_bce' main.go。

以上一節(jié)的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。兩者都是插入邊界檢測的證明，檢查的內(nèi)容差不多，只有微小的差別，有興趣可以看ssa怎么生成兩者代碼的：https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/rewriteAMD64.go#L25798

那么這些檢查怎么消除呢？具體來說可以分為好幾種情況，但隨著編譯器的發(fā)展肯定會有不少變化，所以我不準備一一列舉。

既然不列舉，那肯定有大致通用的規(guī)則：如果使用index訪問slice前的表達式里可以推算出當前index值不會越界，那么檢查就能消除。

舉幾個例子：

s1 := make([]T, 10)
s1[9] // 常數(shù)索引值編譯時就能判斷是否越界，所以不需要插入運行時的檢測。
_ = s1[i&6]   // 索引的值肯定在0-6之間，檢查被消除
 
var s2 []int
_ = s2[:i] // 檢查
_ = s2[:i] // 重復(fù)訪問，消除邊界檢查
_ = s2[:i+1] // 檢查
_ = s2[:i+1] // 重復(fù)的表達式，檢查過了所以檢查被消除
 
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] // 這里會邊界檢查。這里還利用了前面說的合理設(shè)置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是有符號整數(shù)，可能會小于0
    }
}
 
func f(s []int, i int) {
    if 0 < i && i < len(s) {
        fmt.Println(s[i+2]) // 消除不了，因為i是有符號整數(shù)，i+2萬一發(fā)生溢出，索引值會因為繞回而變成負數(shù)
    }
}

有了這些知識，前面的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:] // 忽略掉已經(jīng)處理過的四個元素，而且因為len(s) >= 4，所以這里也不需要檢查
	}
	return sum
}

這樣檢查就完全消除了，但多了一次slice的賦值。

然而我這的例子實在是太簡單了，性能測試顯示邊界檢查消除并沒有帶來性能提升，完全消除了檢查的那個例子反而因為額外的slice賦值操作帶來了輕微的性能下降（和消除到只剩一次檢查的比較）。

如果想要看效果更明顯的例子，可以參考這篇博客。

適用場景：能有效利用len(slice)的結(jié)果的地方可以嘗試BCE。

其他場合需要通過性能測試來判斷是否有提升以及提升的幅度。像這樣既不像設(shè)置slice表達式cap值那樣增強安全性又不像用make批量添加空值那樣增加可讀性的改動，個人認為除非真的是性能瓶頸而且沒有其他優(yōu)化手段，否則提升低于5%的話建議不要做這類改動。

并行處理slice

前面說到了循環(huán)展開，基于這一手段更進一步的優(yōu)化就是并行處理了。這里的并行不是指SIMD，而是依賴goroutine實現(xiàn)的并行。

能并行的前提是slice元素的處理不會互相依賴，比如s[1]的處理依賴于s[0]的處理結(jié)果這樣的。

在能確定slice的處理可以并行后，就可以寫一些并行代碼了，比如并行求和：

func Sum(s []int64) int64 {
	// 假設(shè)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()
}

很簡單的代碼。和循環(huán)展開一樣，需要額外料理數(shù)量不夠一次處理的剩余的元素。

另外協(xié)程的創(chuàng)建銷毀以及數(shù)據(jù)的同步都是比較耗時的，如果slice里元素很少的話并行處理反而得不償失。

適用場景：slice里元素很多、對元素的處理可以并行互不干擾，還有重要的一點，golang程序可以使用超過一個cpu核心保證代碼真正可以“并行”運行。

復(fù)用

復(fù)用slice是個常見的套路，其中復(fù)用[]byte是最為常見的。

復(fù)用可以利用sync.Pool，也可以像下面這樣：

buf := make([]byte, 1024)
for {
	read(buf)
	...
	// reuse
	buf = buf[:0]
}

其中buf = buf[:0]使得slice的cap不變，length清零，這樣就可以復(fù)用slice的內(nèi)存了。使用sync.Pool時也需要這樣使slice的長度為零。

此外使用sync.Pool時還要注意slice的尺寸不能太大，否則同樣會增加gc負擔。一般來說超過1M大小的slice是不建議存進去的，當然還得結(jié)合項目需求和性能測試才能決定尺寸的上限。

適用場景：你的slice內(nèi)存可以反復(fù)被使用（最好是能直接重用連清理都可以不做的那種，清理會讓優(yōu)化效果打點折扣）并且多次創(chuàng)建slice確實成為了性能瓶頸時。

高效刪除多個元素

刪除元素也是常見需求，這里我們也要分三種情況來討論。

這三種情況都包含在標準庫的slices.Delete里了，所以比起自己寫我更推薦你用標準庫。因此本節(jié)沒有適用場景這一環(huán)境，但每一小節(jié)針對一些特殊場景給出了相應(yīng)的建議。

刪除所有元素

如果刪除元素后也不打算復(fù)用slice了，直接設(shè)置為nil就行。

如果還要復(fù)用內(nèi)存，利用我們在復(fù)用那節(jié)里提到的s := s[:0]就行，不過光這樣還不夠，為了防止內(nèi)存泄漏還得把刪除的元素全部清零，在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內(nèi)置函數(shù)，代碼可以大幅簡化：

func deleteSlice[T any, S ~[]T](s S) S {
	clear(s)
	return s[:0]
}

兩種寫法的性能是一樣的，因為go專門對for-range循環(huán)寫入零值做了優(yōu)化，效果和直接用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

但是如果循環(huán)的形式不是for-range，那么就吃不到這個優(yōu)化了：

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

速度相差一個數(shù)量級。對“循環(huán)寫零”優(yōu)化有興趣的可以在這看到是這么實現(xiàn)的：arrayclear。這個優(yōu)化對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
	}
}

從結(jié)果來看只是刪除操作的話沒有太大區(qū)別：

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

所以選用哪種方式主要取決于你后續(xù)是否還要復(fù)用slice的內(nèi)存，需要復(fù)用就用clear，否則直接設(shè)為nil。

刪除頭部或尾部的元素

刪除尾部元素是最簡單的，最快的方法只有s = s[:index]這一種。注意別忘了要用clear清零被刪除的部分。

這個方法唯一的缺點是被刪除的部分的內(nèi)存不會釋放，通常這沒有壞處而且能在新添加元素時復(fù)用這些內(nèi)存，但如果你不會再復(fù)用這些內(nèi)存并且對浪費很敏感，那只能分配一個新slice然后把要留下的元素復(fù)制過去了，但要注意這么做的話會慢很多而且在刪除的過程中要消費更多內(nèi)存（因為新舊兩個slice得同時存在）。

刪除頭部元素的選擇就比較多了，常見的有兩種（我們需要保持元素之間的相對順序）：s = s[index+1:]或者s = append(s[:0], s[index+1:]...)。

前者是新建一個slice，底層數(shù)組起始為止指向原先slice的index+1處，注意雖然底層數(shù)組被復(fù)用了，但cap實際上是減小的，而且被刪除部分的內(nèi)存沒有機會再被復(fù)用了。這種方法需要在刪除前先把元素清零。

后一種則不會創(chuàng)建新的slice，它把index+1開始的元素平移到了slice的頭部，這樣也是刪除了頭部的元素（被覆蓋掉了）。使用這種方案不需要主動清零元素，你要是不放心移動后尾部剩下的空間也可以選擇使用clear但一般不建議。

理論上前者真正地浪費了內(nèi)存但性能更好，不過性能始終要用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:]...)
	}
}

測試結(jié)果顯示確實第一種方法快：

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慢了一個數(shù)量級，即使memmove已經(jīng)得到了相當多的優(yōu)化，在內(nèi)存里移動數(shù)據(jù)還是很慢的。

在實際應(yīng)用中應(yīng)該根據(jù)內(nèi)存利用效率和運行速度綜合考慮選擇合適的方案。

刪除在中間位置的元素

刪除中間部分的元素還要保持相對順序，能用的辦法就只有移動刪除部分后面的元素到前面進行覆蓋這一種辦法：

s := append(s[:index], s[index+n:]...)

這個方法也不需要主動clear被刪除元素，因為它們都被覆蓋掉了。利用append而不是for循環(huán)除了前面說的for循環(huán)優(yōu)化差之外還有代碼更簡潔和能利用memmove這兩個優(yōu)勢。

因為方法唯一沒啥參照物，所以性能就不測試了。

減輕GC掃描壓力

簡單的說，盡量不要在slice里存放大量的指針或者包含指針的結(jié)構(gòu)體。指針越多gc在掃描對象時需要做的工作就越多，最后會導(dǎo)致性能下降。

更具體的解釋和性能測試可以看這篇。

適用場景：無特殊需求且元素大小不是特別大的，存值優(yōu)于存指針。

作為代價，如果選擇了存值，得小心額外的復(fù)制導(dǎo)致的開銷。

總結(jié)

按個人經(jīng)驗來看，使用頻率最高的幾個優(yōu)化手段依次是預(yù)分配內(nèi)存、避免for-ranges踩坑、slice復(fù)用、循環(huán)展開。從提升來看這幾個也是效果最明顯的。

編譯器的優(yōu)化不夠給力的話就只能自己想辦法用這些優(yōu)化技巧了。

有時候也可以利用逃逸分析規(guī)則來做優(yōu)化，但正如這篇文章所說，絕大多數(shù)情況下你都不應(yīng)該考慮逃逸分析。

還有另外一條路：給go編譯器共享代碼提升編譯產(chǎn)物的性能。雖然阻力會很大，但我還是相信有大佬一定能做到的。這也是我為什么會把編譯器怎么做優(yōu)化的代碼貼出來，拋磚引玉嘛。

還有最重要的一點：性能問題不管是定位還是優(yōu)化，都必須以性能測試為依據(jù)，切記不可光靠“經(jīng)驗”和沒有事實依據(jù)支撐的“推論”。

最后我希望這篇文章能成為大家優(yōu)化性能時的趁手工具，而不是面試時背的八股文。

以上就是golang slice中常見性能優(yōu)化手段總結(jié)的詳細內(nèi)容，更多關(guān)于go slice性能優(yōu)化的資料請關(guān)注腳本之家其它相關(guān)文章！