歡迎訪問我的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的基本功能已經掌握，接下來的《提高篇》會有更多進階內容，協助咱們完成更加全面精確的基準測試，敬請期待，欣宸原創，必不讓您失望