golang slice相關(guān)常見的性能優(yōu)化手段

介紹一些開發(fā)中常用的slice關(guān)聯(lián)的性能優(yōu)化手段。鑒于golang編譯器本身捉雞的優(yōu)化能力，優(yōu)化的成本就得分?jǐn)傇陂_發(fā)者自己的頭上了。

這篇文章會(huì)介紹的優(yōu)化手段是下面這幾樣：

創(chuàng)建slice時(shí)預(yù)分配內(nèi)存
操作slice前預(yù)分配內(nèi)存
slice表達(dá)式中合理設(shè)置cap值
添加多個(gè)零值元素的優(yōu)化
循環(huán)展開
避免for-range復(fù)制數(shù)據(jù)帶來的損耗
邊界檢查消除
并行處理slice
復(fù)用slice的內(nèi)存
高效刪除多個(gè)元素
減輕GC掃描壓力

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

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

本文比較長，所以我建議可以挑自己感興趣的內(nèi)容看，有時(shí)間再通讀。

本文索引

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

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

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

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

循環(huán)展開

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

避免復(fù)制

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

BCE邊界檢查消除

并行處理slice

復(fù)用

高效刪除多個(gè)元素

刪除所有元素

刪除頭部或尾部的元素

刪除在中間位置的元素

減輕GC掃描壓力

總結(jié)

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

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

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

具體做法如下：

s1 := make([]T, 0, 預(yù)分配的元素個(gè)數(shù))

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

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

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

另外slice采用的擴(kuò)容策略有時(shí)候會(huì)造成浪費(fèi)，比如下面這樣：

func main() {
    var a []int
    for i := 0; i < 2048; i++ {
            a = append(a, i)
    }
    fmt.Println(cap(a)) // go1.22: 2560
}

可以看到，我們添加了2048個(gè)元素，但go最后給我們分配了2560個(gè)元素的內(nèi)存，浪費(fèi)了將近500個(gè)。

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

適用場景：

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

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

預(yù)分配內(nèi)存還有另一個(gè)好處：如果分配的大小是常量或者常量表達(dá)式，則有機(jī)會(huì)被逃逸分析認(rèn)定為大小合適分配在棧上，從而使性能更進(jìn)一步提升。這也是編譯器實(shí)現(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臨時(shí)變量，分配在棧上
	}

	// 逃逸了，這時(shí)候會(huì)生成調(diào)用runtime.makeslice的代碼
    // runtime.makeslice用mallocgc從堆分配內(nèi)存
}

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

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

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

當(dāng)然之前也可以，不過得繞些彎路，有興趣可以去看下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進(jìn)行了比較：

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é)的完全一樣：避免了多次擴(kuò)容帶來的開銷。

同時(shí)節(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的機(jī)制來擴(kuò)容，但它可以更充分得利用內(nèi)存，避免了浪費(fèi)。

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

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

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

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

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

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

為啥要加這個(gè)參數(shù)呢？因?yàn)榭梢韵拗魄衅L問的范圍，避免意外地改變數(shù)據(jù)。

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

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

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進(jìn)行比較，平均來說使用slice[1:5:5]的代碼要快3%左右。

事實(shí)上這里有一個(gè)go的小優(yōu)化，當(dāng)切片表達(dá)式里第二個(gè)參數(shù)和第三個(gè)參數(shù)一樣的時(shí)候，cap可以不用額外計(jì)算，直接取之前算出來的length就行了。這會(huì)少幾次內(nèi)存訪問和一個(gè)減法運(yùn)算。

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

// 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)
        // 計(jì)算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會(huì)默認(rèn)設(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進(jìn)行邊界檢查

	// 先理解成加減乘除的運(yùn)算符就行
	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)
	}

	// 計(jì)算slice的內(nèi)存從那里開始的，在這不重要忽略

	return rptr, rlen, rcap
}

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

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

正是因?yàn)檫@個(gè)小小的優(yōu)化帶來了細(xì)微的性能提升。

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

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

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

上面這個(gè)場景估計(jì)能占到一半左右，當(dāng)然還有很多不符合上述要求的場景，所以不要生搬硬套，一切以性能測試為準(zhǔn)。

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

向slice添加多個(gè)零值元素的優(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) 1
1 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) 1
1 all samples are equal

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

秘密依然在編譯器里。

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

前者的流程是這樣的：

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

使用make時(shí)的流程是這樣的：

檢查s1的cap，不夠的情況下要擴(kuò)容
對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)建臨時(shí)的slice，以及memclr做的事比copy更少也更簡單所以更快。

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

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

循環(huán)展開

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

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

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

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

你問go呢？那是自然沒有的。在運(yùn)行時(shí)性能和語言表現(xiàn)力之間，go選擇了編譯速度。編譯得確實(shí)快，然而優(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個(gè)int的slice，首先和一個(gè)循環(huán)里處理四個(gè)數(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) 1
1 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) 1
1 all samples are equal

提升了將近67%，相當(dāng)之大了。然后我們和一次處理8個(gè)數(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%，相比一次只處理四個(gè)，處理8個(gè)的方法快了30%。

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

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

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

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

避免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”的性能陷阱才對。

先說說陷阱在哪。

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

避免復(fù)制

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

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

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
}

// 會(huì)導(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的語義，從以前會(huì)復(fù)用循環(huán)變量變成了每輪循環(huán)都創(chuàng)建新的循環(huán)變量，這會(huì)使一部分存在復(fù)制開銷的for-range循環(huán)變得更慢。

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

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

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

這個(gè)坑在于，range遍歷字符串的時(shí)候會(huì)把字符串的內(nèi)容轉(zhuǎn)換成一個(gè)個(gè)rune，這一步會(huì)帶來開銷，尤其是字符串里只有ascii字符的時(shí)候。

寫個(gè)簡單例子看看性能損耗有多少：

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。換句話說如果你沒注意到這個(gè)坑，那么就要白白丟失這么多性能了。

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

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

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

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

BCE邊界檢查消除

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

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

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

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

如何查看編譯器在哪里插入了檢查呢？可以用下面這個(gè)命令：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

目前你會(huì)看到兩種輸出IsInBounds和IsSliceInBounds。兩者都是插入邊界檢測的證明，檢查的內(nèi)容差不多，只有微小的差別，有興趣可以看ssa怎么生成兩者代碼的：https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/rewriteAMD64.go#L25798

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

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

舉幾個(gè)例子：

s1 := make([]T, 10)
s1[9] // 常數(shù)索引值編譯時(shí)就能判斷是否越界，所以不需要插入運(yùn)行時(shí)的檢測。
_ = s1[i&6]   // 索引的值肯定在0-6之間，檢查被消除

var s2 []int
_ = s2[:i] // 檢查
_ = s2[:i] // 重復(fù)訪問，消除邊界檢查
_ = s2[:i+1] // 檢查
_ = s2[:i+1] // 重復(fù)的表達(dá)式，檢查過了所以檢查被消除

func f(s []int) int {
    if len(s) < 3 {
        panic("error")
    }

    return s[1] + s[2] // 前面的if保證了這兩個(gè)訪問一定不會(huì)越界，所以檢查可以消除
}

// 一種通過臨時(shí)變量避免多次邊界檢測的常用作法
func f2(s []int) int {
    tmp := s[:4:4] // 這里會(huì)邊界檢查。這里還利用了前面說的合理設(shè)置slice表達(dá)式的cap避免額外開銷
    a := tmp[2] // tmp那里的檢查保證了這里不會(huì)越界，因此不會(huì)再檢查
    b := tmp[3] // 同上
    return a+b
}

我沒列出所有例子，想看的可以去這里。

當(dāng)然有一些隱藏的不能消除檢查的場景：

func f(s []int, i int) {
    if i < len(s) {
        fmt.Println(s[i]) // 消除不了，因?yàn)閕是有符號整數(shù)，可能會(huì)小于0
    }
}

func f(s []int, i int) {
    if 0 < i && i < len(s) {
        fmt.Println(s[i+2]) // 消除不了，因?yàn)閕是有符號整數(shù)，i+2萬一發(fā)生溢出，索引值會(huì)因?yàn)槔@回而變成負(fù)數(shù)
    }
}

有了這些知識(shí)，前面的unroll4有四次邊界檢查，實(shí)際上用不著這么多，因此可以改成下面這樣：

func unroll4(s []int) int {
	sum := 0
	for i := 0; i < len(s); i += 4 {
		tmp := s[i : i+4 : i+4] // 只有這里會(huì)檢查一次
		sum += tmp[0]
		sum += tmp[1]
		sum += tmp[2]
		sum += tmp[3]
	}
	return sum
}

這么做實(shí)際上還是會(huì)檢查一次，能不能完全消除呢？

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)處理過的四個(gè)元素，而且因?yàn)閘en(s) >= 4，所以這里也不需要檢查
	}
	return sum
}

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

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

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

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

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

并行處理slice

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

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

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

func Sum(s []int64) int64 {
	// 假設(shè)s的長度是4000
	var sum atomic.Int64
	var wg sync.WaitGroup
	// 每個(gè)goroutine處理800個(gè)
	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ù)的同步都是比較耗時(shí)的，如果slice里元素很少的話并行處理反而得不償失。

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

復(fù)用

復(fù)用slice是個(gè)常見的套路，其中復(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時(shí)也需要這樣使slice的長度為零。

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

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

高效刪除多個(gè)元素

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

這三種情況都包含在標(biāo)準(zhǔn)庫的slices.Delete里了，所以比起自己寫我更推薦你用標(biāo)準(zhǔn)庫。因此本節(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]
}

兩種寫法的性能是一樣的，因?yàn)間o專門對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，那么就吃不到這個(gè)優(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

速度相差一個(gè)數(shù)量級。對“循環(huán)寫零”優(yōu)化有興趣的可以在這看到是這么實(shí)現(xiàn)的：arrayclear。這個(gè)優(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[:] // 防止編譯器認(rèn)為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清零被刪除的部分。

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

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

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

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

理論上前者真正地浪費(fèi)了內(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個(gè)元素
		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é)果顯示確實(shí)第一種方法快：

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

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

刪除在中間位置的元素

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

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

這個(gè)方法也不需要主動(dòng)clear被刪除元素，因?yàn)樗鼈兌急桓采w掉了。利用append而不是for循環(huán)除了前面說的for循環(huán)優(yōu)化差之外還有代碼更簡潔和能利用memmove這兩個(gè)優(yōu)勢。

因?yàn)榉椒ㄎㄒ粵]啥參照物，所以性能就不測試了。

減輕GC掃描壓力

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

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

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

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

總結(jié)

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

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

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

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

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

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

posted @ 2024-10-25 11:06 apocelipes 閱讀(1509) 評論(0) 收藏舉報(bào)

刷新頁面返回頂部

apocelipes