Go語言基準測試(benchmark)三部曲之二：記憶體篇
2023-11-02 12:02:18
歡迎存取我的GitHub
這裡分類和彙總了欣宸的全部原創(含配套原始碼)：https://github.com/zq2599/blog_demos
本篇概覽
- 本文是《Go語言基準測試(benchmark)三部曲》的第二篇，目標是掌握如何用基準測試來觀察被測方法的記憶體分配情況
- 今天除了常規的操作，即指定引數增加記憶體相關的測試結果，咱們還要針對記憶體分配問題增加幾個方法用於對比驗證，最終達到根據基準測試發現記憶體問題的目標
基本操作
- 檢視方法中的記憶體使用情況，請在原來的benchmark測試命令中增加-benchmem引數，完整命令如下，用的是前文的BenchmarkFib和BenchmarkParallelFib方法做基準測試
go test -bench='Fib$' -benchmem .
- 測試結果如下，竟然沒有使用記憶體，不過想想也是，fib方法主要是斐波那契數列計算，未涉及到記憶體分配，看來這個例子不具有說明性，咱們需要寫兩個涉及到記憶體分配的方法，再對他們做基準測試看看效果
新增兩個方法用於基準測試
- 為了展現記憶體分配的不同程度影響，這裡會編寫兩個方法用於對比測試
- 這兩個方法的功能是一樣的：產生N個亂數（N是方法的入參），然後放入切片中
- 雖然功能一樣，但是這兩個方法最大的不同就是：名為newSlice的方法，建立切片的時候沒有指定切片容量，另一個名為newSliceWithCap的方法在建立切片的時候指定了切片容量
- newSlice和newSliceWithCap方法的原始碼如下，都在main.go中
// 往切片中放入指定數量的亂數，這個切片沒有提前設定容量
func newSlice(n int) []int {
rand.Seed(time.Now().UnixNano())
// 注意，這裡在生成切片的時候並沒有指定容量
nums := make([]int, 0)
for i := 0; i < n; i++ {
nums = append(nums, rand.Int())
}
return nums
}
// 往切片中放入指定數量的亂數，這個切片提前設定了容量
func newSliceWithCap(n int) []int {
rand.Seed(time.Now().UnixNano())
// 注意，這裡在生成切片的時候指定了容量
nums := make([]int, 0, n)
for i := 0; i < n; i++ {
nums = append(nums, rand.Int())
}
return nums
}
- 接下來在main_test.go檔案中增加基準測試的程式碼，先準備三個常數，後面會用到
const (
SLICE_LENGTH_MILLION = 1000000 // 往切片中新增資料的長度，百萬
SLICE_LENGTH_TEN_MILLION = 10000000 // 往切片中新增資料的長度，千萬
SLICE_LENGTH_HUNDRED_MILLION = 100000000 // 往切片中新增資料的長度，億
)
- 然後是兩個基準測試的方法，分別用於測試newSlice和newSliceWithCap：
func BenchmarkNewSlice(b *testing.B) {
for n := 0; n < b.N; n++ {
newSlice(SLICE_LENGTH_MILLION)
}
}
func BenchmarkNewSliceWithCap(b *testing.B) {
for n := 0; n < b.N; n++ {
newSliceWithCap(SLICE_LENGTH_MILLION)
}
}
- 程式碼寫完了，從理論上分析，切片未指定容量，就會隨著內容的增加發生新的記憶體分配，因此newSlice的記憶體使用和記憶體分配都應該超過newSliceWithCap，咱們來測試一下，看資料和推論是否匹配
- 執行以下命令，正規表示式的意思是隻執行BenchmarkNewSlice和BenchmarkNewSliceWithCap這兩個方法
go test -bench='BenchmarkNewSlice$|BenchmarkNewSliceWithCap$' -benchmem .
- 結果如下，可見未指定容量的切片在儲存資料時會觸發擴容，會分配更多記憶體，記憶體分配次數也會跟多，每次方法執行的耗時也更多，而提前指定了容量的切片，中途不再發生擴容，記憶體分配量更小，方法執行耗時也更少（對我們的開發還是有指導意義的）
go test -bench='BenchmarkNewSlice$|BenchmarkNewSliceWithCap$' -benchmem .
goos: darwin
goarch: arm64
pkg: benchmark-demo
BenchmarkNewSlice-8 68 16568869 ns/op 41678153 B/op 38 allocs/op
BenchmarkNewSliceWithCap-8 84 14098503 ns/op 8003589 B/op 1 allocs/op
PASS
ok benchmark-demo 2.769s
同一方法的不同數量級對比
- 經過前面的測試，可以確定newSliceWithCap方法由於未指定切片容量，在儲存資料的中途會觸發擴容，從而導致記憶體分配的大小和次數都會增加
- 這個結果是對比newSlice方法得出的，此方法指定了切片容量的，接下里咱們換種測試方式：讓newSliceWithCap內的切片分別存入不同數量級的資料，觀察此方法在面對這些資料時的記憶體分配情況
- 在main_test.go中增加一個方法
func testNewSlice(len int, b *testing.B) {
for n := 0; n < b.N; n++ {
newSlice(len)
}
}
- 現在只要新增多個BenchmarkXXX方法，每個方法都呼叫testNewSlice並傳入不同數量級的數位，就能實現對比測試了，詳細程式碼如下，咱們分解測試百萬、千萬、億這三個級別的資料量下newSlice的記憶體分配情況
func BenchmarkNewSlicMillion(b *testing.B) {
testNewSlice(SLICE_LENGTH_MILLION, b)
}
func BenchmarkNewSlicTenMillion(b *testing.B) {
testNewSlice(SLICE_LENGTH_TEN_MILLION, b)
}
func BenchmarkNewSlicHundredMillion(b *testing.B) {
testNewSlice(SLICE_LENGTH_HUNDRED_MILLION, b)
}
- 執行以下命令測試，只會匹配到上面新增的三個測試方法
go test -bench='Million$' -benchmem .
- 同一方法，處理不同數量級內容的對比測試結果如下，可見不指定容量的切片存入資料時，資料量越大，對效能的影響越嚴重
go test -bench='Million$' -benchmem .
goos: darwin
goarch: arm64
pkg: benchmark-demo
BenchmarkNewSlicMillion-8 67 16283754 ns/op 41678145 B/op 38 allocs/op
BenchmarkNewSlicTenMillion-8 7 159938941 ns/op 492000525 B/op 49 allocs/op
BenchmarkNewSlicHundredMillion-8 1 2242365417 ns/op 4589008224 B/op 60 allocs/op
- 至此，基準測試的記憶體篇就完成了，相信大家對benchmark的基本功能已經掌握，接下來的《提高篇》會有更多進階內容，協助咱們完成更加全面精確的基準測試，敬請期待，欣宸原創，必不讓您失望