Go 效能分析之案例一
阿新 • • 發佈：2019-06-17
思考
相信大家在實際的專案開發中會遇到這麼一個事，有的程式設計師寫的程式碼不僅bug少，而且效能高；而有的程式設計師寫的程式碼能否流暢的跑起來，都是一個很大問題。
而我們今天要討論的就是一個關於效能優化的案例分析。
案例分析
我們先來構造一些基礎資料（長度為10億的切片，並賦上值）：
var testData = GenerateData()
// generate billion slice data
func GenerateData() []int {
data := make([]int, 1000000000)
for key, _ := range data {
data[key] = key % 128
}
return data
}
// get length
func GetDataLen() int {
return len(testData)
}
案例一
// case one
func CaseSumOne(result *int) {
data := GenerateData()
for i := 0; i < GetDataLen(); i++ {
*result += data[i]
}
}
// case two
func CaseSumTwo(result *int) {
data := GenerateData()
dataLen := GetDataLen()
for i := 0; i < dataLen; i++ {
*result += data[i]
}
}
執行結果
$ go test -bench=. goos: windows goarch: amd64 BenchmarkCaseSumOne-8 1 7439749000 ns/op BenchmarkCaseSumTwo-8 1 2529266700 ns/op PASS ok _/C_/go-code/perform/case-one 14.059s
問題分析
- CaseSumTwo執行效率是CaseSumOne的2.94倍，快了近三倍，這是為什麼呢？
- 我想這個其實很容易猜到，這裡有一個連續的函式呼叫“GetDataLen()”,
我們來看下兩個函式的彙編，做個簡單的對比：
函式CaseSumOne
"".CaseSumOne STEXT size=83 args=0x4 locals=0xc
0x0000 00000 (point.go:22) TEXT "".CaseSumOne(SB), $12-4
...
// point.go:24 -> for i := 0; i < GetDataLen(); i++
0x0021 00033 (point.go:24) PCDATA $2, $2
0x0021 00033 (point.go:24) PCDATA $0, $1
0x0021 00033 (point.go:24) MOVL "".result+16(SP), DX
0x0025 00037 (point.go:24) XORL BX, BX
0x0027 00039 (point.go:24) JMP 47
0x0029 00041 (point.go:25) MOVL (CX)(BX*4), BP // CX迴圈計數器
0x002c 00044 (point.go:25) ADDL BP, (DX)
0x002e 00046 (point.go:24) INCL BX // i++
0x002f 00047 (point.go:24) MOVL "".testData+4(SB), BP // 棧指標暫存器
0x0035 00053 (point.go:24) CMPL BX, BP
0x0037 00055 (point.go:24) JGE 65
...
0x0045 00069 (point.go:25) CALL runtime.panicindex(SB)
0x004c 00076 (point.go:22) CALL runtime.morestack_noctxt(SB)
...
函式CaseSumTwo
"".CaseSumTwo STEXT size=83 args=0x4 locals=0xc
0x0000 00000 (point.go:30) TEXT "".CaseSumTwo(SB), $12-4
...
// point.go:32 -> dataLen := GetDataLen()
// point.go:33 -> for i := 0; i < dataLen; i++ {
0x0021 00033 (point.go:32) MOVL "".testData+4(SB), DX
0x0027 00039 (point.go:33) PCDATA $2, $2
0x0027 00039 (point.go:33) PCDATA $0, $1
0x0027 00039 (point.go:33) MOVL "".result+16(SP), BX
0x002b 00043 (point.go:33) XORL BP, BP
0x002d 00045 (point.go:33) JMP 53
0x002f 00047 (point.go:34) MOVL (AX)(BP*4), SI
0x0032 00050 (point.go:34) ADDL SI, (BX)
0x0034 00052 (point.go:33) INCL BP
0x0035 00053 (point.go:33) CMPL BP, DX
0x0037 00055 (point.go:33) JGE 65
...
0x0045 00069 (point.go:34) CALL runtime.panicindex(SB)
0x004c 00076 (point.go:30) CALL runtime.morestack_noctxt(SB)
...
比較結論
不難發現主要的區別是在CaseSumOne中多了這麼一行：
0x002f 00047 (point.go:24) MOVL "".testData+4(SB), BP其實雖然只有一行，但是對於函式“GetDataLen”裡需要呼叫的指令對CPU的消耗：
"".GetDataLen STEXT size=36 args=0x4 locals=0x0
0x0000 00000 (point.go:17) TEXT "".GetDataLen(SB), $0-4 //
0x0000 00000 (point.go:17) MOVL TLS, CX
0x0007 00007 (point.go:17) MOVL (CX)(TLS*2), CX
0x000d 00013 (point.go:17) CMPL SP, 8(CX)
0x0010 00016 (point.go:17) JLS 29
0x0012 00018 (point.go:17) FUNCDATA $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
0x0012 00018 (point.go:17) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
0x0012 00018 (point.go:17) FUNCDATA $3, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
0x0012 00018 (point.go:18) PCDATA $2, $0
0x0012 00018 (point.go:18) PCDATA $0, $0
0x0012 00018 (point.go:18) MOVL "".testData+4(SB), AX // 暫存器定址 AX = lenVAL
0x0018 00024 (point.go:18) MOVL AX, "".~r0+4(SP) // SP = AX = lenVal
0x001c 00028 (point.go:18) RET
0x001d 00029 (point.go:18) NOP
0x001d 00029 (point.go:17) PCDATA $0, $-1
0x001d 00029 (point.go:17) PCDATA $2, $-1
0x001d 00029 (point.go:17) CALL runtime.morestack_noctxt(SB) // 壓棧
...
雖然，看似小小一行程式碼的區別，但是在指令級的角度上，進行了建立棧空間、壓棧、定址、賦值等一系列操作，況且這裡進行了迴圈呼叫。
案例二
// case two
func CaseSumTwo(result *int) {
data := GenerateData()
dataLen := GetDataLen()
for i := 0; i < dataLen; i++ {
*result += data[i]
}
}
// case three
func CaseSumThree(result *int) {
data := GenerateData()
dataLen := GetDataLen()
tmp := *result
for i:= 0; i < dataLen; i++ {
tmp += data[i]
}
*result = tmp
}
執行結果
$ go test -bench=. goos: windows goarch: amd64 BenchmarkCaseSumTwo-8 1 2529266700 ns/op BenchmarkCaseSumThree-8 1 1657554600 ns/op PASS ok _/C_/go-code/perform/case-one 8.2773
問題分析
- 雖然對連續函式呼叫進行了優化，但是CaseSumThree對執行效率還是高於CaseSumTwo1.52倍，還有哪些情況會影響執行效能呢？
我們再來對比下“CaseSumTwo”和“CaseSumThree”對彙編原始碼：
函式CaseSumTwo
"".CaseSumTwo STEXT size=83 args=0x4 locals=0xc
0x0000 00000 (point.go:30) TEXT "".CaseSumTwo(SB), $12-4
...
// point.go:31 -> data := GenerateData()
// point.go:34 -> *result += data[i]
0x001a 00026 (point.go:31) MOVL (SP), AX
0x0027 00039 (point.go:33) MOVL "".result+16(SP), BX
0x002f 00047 (point.go:34) MOVL (AX)(BP*4), SI // 棧暫存器移動四個位元組， -> SI源變址暫存器
0x0032 00050 (point.go:34) ADDL SI, (BX) // SI
0x0034 00052 (point.go:33) INCL BP
0x0035 00053 (point.go:33) CMPL BP, DX
0x0037 00055 (point.go:33) JGE 65
0x0039 00057 (point.go:34) TESTB AX, (BX)
0x003b 00059 (point.go:34) CMPL BP, CX
0x003d 00061 (point.go:34) JCS 47
0x003f 00063 (point.go:34) JMP 69
0x0041 00065 (<unknown line number>) PCDATA $2, $-2
0x0041 00065 (<unknown line number>) PCDATA $0, $-2
0x0041 00065 (<unknown line number>) ADDL $12, SP
0x0044 00068 (<unknown line number>) RET
0x0045 00069 (point.go:34) PCDATA $2, $0
0x0045 00069 (point.go:34) PCDATA $0, $1
0x0045 00069 (point.go:34) CALL runtime.panicindex(SB)
0x004a 00074 (point.go:34) UNDEF
0x004c 00076 (point.go:34) NOP
函式CaseSumThree
"".CaseSumThree STEXT size=97 args=0x4 locals=0x10
0x0000 00000 (point.go:39) TEXT "".CaseSumThree(SB), $16-4
...
// point.go:40 -> data := GenerateData()
// point.go:42 -> tmp := *result
// point.go:44 -> tmp += data[i]
// point.go:46 -> *result = tmp
0x001a 00026 (point.go:40) MOVL (SP), AX
0x0021 00033 (point.go:42) PCDATA $2, $2
0x0021 00033 (point.go:42) PCDATA $0, $1
0x0021 00033 (point.go:42) MOVL "".result+20(SP), DX
0x0025 00037 (point.go:42) MOVL (DX), BX // ->BX資料指標暫存器
0x0027 00039 (point.go:41) MOVL "".testData+4(SB), BP
0x002d 00045 (point.go:41) XORL SI, SI
0x002f 00047 (point.go:43) JMP 67
0x0031 00049 (point.go:43) LEAL 1(SI), DI
0x0034 00052 (point.go:43) MOVL DI, "".i+12(SP) // 移動DI到棧指標12位元組的位置
0x0038 00056 (point.go:44) MOVL (AX)(SI*4), DI // 源變址暫存器移動四個位元組（32位），-> 目的變址暫存器
0x003b 00059 (point.go:44) ADDL DI, BX // DI+BX
0x003d 00061 (point.go:43) MOVL "".i+12(SP), DI
0x0041 00065 (point.go:43) MOVL DI, SI
0x0043 00067 (point.go:43) CMPL SI, BP
0x0045 00069 (point.go:43) JGE 77
0x0047 00071 (point.go:44) CMPL SI, CX
0x0049 00073 (point.go:44) JCS 49
0x004b 00075 (point.go:44) JMP 83
0x004d 00077 (point.go:46) PCDATA $2, $0
0x004d 00077 (point.go:46) MOVL BX, (DX)
0x004f 00079 (point.go:47) ADDL $16, SP
0x0052 00082 (point.go:47) RET
0x0053 00083 (point.go:44) CALL runtime.panicindex(SB)
...
比較結論
CaseSumTwo函式，在進行ADDL之前，因為“*result”為指標變數，所以不能直接與data[i]運算。因此需要建立一個棧空間，並指向data的地址並，然後通過移動棧指標後得到下一個值的地址，並賦與SI。
CaseSumThree函式，在進行ADDL執行前，建立了一個值變數，那麼在執行ADDL的時候，只需要移動SI獲取下一個data的值就可以直接進行算數運算，中間少了地址的引用的棧的操作。
總結
本章主要講了三個點：
- 消除迴圈的低效率
- 減少過程呼叫
- 消除不必要的記憶體引用
引用《深入計算機系統原理》一書中對效能優化所提到的三個方面：
- 高階設計，為遇到的問題選擇適當的演算法和資料結構。要特別警覺，避免使用那些會漸進地產生糟糕效能的演算法或編碼技術。
- 基本編碼原則，從指令的角度考慮，開發中應如何編碼，才能減少執行的指令。
- 低階優化，針對現代處理器，如何讓cpu的流水線儘量飽合。
所以，一個優秀的程式設計師在寫每一行程式碼，定義每一個變數，也許背後思考的就會更