在上一篇關於字符串拼接的文章 Go語言字符串高效拼接(一) 中,我們演示的多種字符串拼接的方式,並且使用一個例子來測試了他們的性能,通過對比發現,我們覺得性能高的Builder
並未發揮出其應該的性能,反而+
號拼接,甚至strings.Join
方法的性能更優越,那麼這到底是什麼原因呢?今天我們開始解開他們神祕的面紗,解開謎底。
拼接函數改造
在上一篇的文章的末尾,我已經提出了2個可能性:拼接字符串的數量和拼接字符串的大小,現在我們就開始證明這兩種情況,爲了演示方便,我們把原來的拼接函數修改一下,可以接受一個[]string
類型的參數,這樣我們就可以對切片數組進行字符串拼接,這裏直接給出所有的拼接方法的改造後實現。
func StringPlus(p []string) string{ var s string l:=len(p) for i:=0;i<l;i++{ s+=p[i] } return s } func StringFmt(p []interface{}) string{ return fmt.Sprint(p...) } func StringJoin(p []string) string{ return strings.Join(p,"") } func StringBuffer(p []string) string { var b bytes.Buffer l:=len(p) for i:=0;i<l;i++{ b.WriteString(p[i]) } return b.String() } func StringBuilder(p []string) string { var b strings.Builder l:=len(p) for i:=0;i<l;i++{ b.WriteString(p[i]) } return b.String() }
以上實現中的for
循環我並沒有使用for range
,爲了提高性能,具體原因請參考我的 Go語言性能優化- For Range 性能研究 。
測試用例
以上的字符串拼接函數修改後,我們就可以構造不同大小的切片進行字符串拼接測試了。爲了模擬上次的效果,我們先用10個切片大小的字符串進行拼接測試,和上一篇的測試情形差不多(也是大概10個字符串拼接)。
const BLOG = "http://www.flysnow.org/" func initStrings(N int) []string{ s:=make([]string,N) for i:=0;i<N;i++{ s[i]=BLOG } return s; } func initStringi(N int) []interface{}{ s:=make([]interface{},N) for i:=0;i<N;i++{ s[i]=BLOG } return s; }
這是兩個構建測試用力切片數組的函數,可以生成N個大小的切片。第二個initStringi
函數返回的是[]interface{}
,這是專門爲StringFmt(p []interface{})
拼接函數準備的,減少類型之間的轉換。
有了這兩個生成測試用例的函數,我們就可以構建我們的Go語言性能測試了,我們先測試10個大小的切片。
func BenchmarkStringPlus10(b *testing.B) { p:= initStrings(10) b.ResetTimer() for i:=0;i<b.N;i++{ StringPlus(p) } } func BenchmarkStringFmt10(b *testing.B) { p:= initStringi(10) b.ResetTimer() for i:=0;i<b.N;i++{ StringFmt(p) } } func BenchmarkStringJoin10(b *testing.B) { p:= initStrings(10) b.ResetTimer() for i:=0;i<b.N;i++{ StringJoin(p) } } func BenchmarkStringBuffer10(b *testing.B) { p:= initStrings(10) b.ResetTimer() for i:=0;i<b.N;i++{ StringBuffer(p) } } func BenchmarkStringBuilder10(b *testing.B) { p:= initStrings(10) b.ResetTimer() for i:=0;i<b.N;i++{ StringBuilder(p) } }
在每個性能測試函數中,我們都會調用b.ResetTimer()
,這是爲了避免測試用例準備時間不同,帶來的性能測試效果偏差問題,具體可以參考我的一篇文章 Go語言實戰筆記(二十二)| Go 基準測試 。
我們運行go test -bench=. -run=NONE -benchmem
查看結果。
BenchmarkStringPlus10-8 3000000 593 ns/op 1312 B/op 9 allocs/op BenchmarkStringFmt10-8 5000000 335 ns/op 240 B/op 1 allocs/op BenchmarkStringJoin10-8 10000000 200 ns/op 480 B/op 2 allocs/op BenchmarkStringBuffer10-8 3000000 452 ns/op 864 B/op 4 allocs/op BenchmarkStringBuilder10-8 10000000 231 ns/op 480 B/op 4 allocs/op
通過這次我們可以看到,+
號拼接不再具有優勢,因爲string
是不可變的,每次拼接都會生成一個新的string
,也就是會進行一次內存分配,我們現在是10個大小的切片,每次操作要進行9次進行分配,佔用內存,所以每次操作時間都比較長,自然性能就低下。
http://www.flysnow.org/2018/11/05/golang-concat-strings-performance-analysis.html
可能有讀者記得,我們上一篇文章 Go語言字符串高效拼接(一) 中,+
加號拼接的性能測試中顯示的只有2次內存分配,但是我們用了好多個+
的。
func StringPlus() string{ var s string s+="暱稱"+":"+"飛雪無情"+"\n" s+="博客"+":"+"http://www.flysnow.org/"+"\n" s+="微信公衆號"+":"+"flysnow_org" return s }
再來回顧下這段代碼,的確是有很多+
的,但是隻有2次內存分配,我們可以大膽猜測,是3次s+=
導致的,正常和我們今天測試的10個長度的切片,只有9次內存分配一樣。下面我們通過運行如下命令看下Go編譯器對這段代碼的優化:go build -gcflags="-m -m" main.go
,輸出中有如下內容:
can inline StringPlus as: func() string { var s string; s = <N>; s += "暱稱:飛雪無情\n"; s += "博客:http://www.flysnow.org/\n"; s += "微信公衆號:flysnow_org"; return s }
現在一目瞭然了,其實是編譯器幫我們把字符串做了優化,只剩下3個s+=
這次,採用長度爲10個切片進行測試,也很明顯測試出了Builder
要比Buffer
性能好很多,這個問題原因主要還是[]byte
和string
之間的轉換,Builder
恰恰解決了這個問題。
func (b *Builder) String() string { return *(*string)(unsafe.Pointer(&b.buf)) }
很高效的解決方案。
100個字符串
現在我們測試下100個字符串拼接的情況,對於我們上面的代碼,要改造非常容易,這裏直接給出測試代碼。
func BenchmarkStringPlus100(b *testing.B) { p:= initStrings(100) b.ResetTimer() for i:=0;i<b.N;i++{ StringPlus(p) } } func BenchmarkStringFmt100(b *testing.B) { p:= initStringi(100) b.ResetTimer() for i:=0;i<b.N;i++{ StringFmt(p) } } func BenchmarkStringJoin100(b *testing.B) { p:= initStrings(100) b.ResetTimer() for i:=0;i<b.N;i++{ StringJoin(p) } } func BenchmarkStringBuffer100(b *testing.B) { p:= initStrings(100) b.ResetTimer() for i:=0;i<b.N;i++{ StringBuffer(p) } } func BenchmarkStringBuilder100(b *testing.B) { p:= initStrings(100) b.ResetTimer() for i:=0;i<b.N;i++{ StringBuilder(p) } }
現在運行性能測試,看看100個字符串連接的性能怎麼樣,哪個函數最高效。
BenchmarkStringPlus100-8 100000 19711 ns/op 123168 B/op 99 allocs/op BenchmarkStringFmt100-8 500000 2615 ns/op 2304 B/op 1 allocs/op BenchmarkStringJoin100-8 1000000 1516 ns/op 4608 B/op 2 allocs/op BenchmarkStringBuffer100-8 500000 2333 ns/op 8112 B/op 7 allocs/op BenchmarkStringBuilder100-8 1000000 1714 ns/op 6752 B/op 8 allocs/op
+
號和我們上面分析得一樣,這次是99次內存分配,性能體驗越來越差,在後面的測試中,會排除掉。
fmt
和bufrer
已經的性能也沒有提升,繼續走低。剩下比較堅挺的是Join
和Builder
。
1000 個字符串。
測試用力和上面章節的大同小異,所以我們直接看測試結果。
BenchmarkStringPlus1000-8 1000 1611985 ns/op 12136228 B/op 999 allocs/op BenchmarkStringFmt1000-8 50000 28510 ns/op 24590 B/op 1 allocs/op BenchmarkStringJoin1000-8 100000 15050 ns/op 49152 B/op 2 allocs/op BenchmarkStringBuffer1000-8 100000 23534 ns/op 122544 B/op 11 allocs/op BenchmarkStringBuilder1000-8 100000 17996 ns/op 96224 B/op 16 allocs/op
整體和100個字符串的時候差不多,表現好的還是Join
和Builder
。這兩個方法的使用側重點有些不一樣, 如果有現成的數組、切片那麼可以直接使用Join
,但是如果沒有,並且追求靈活性拼接,還是選擇Builder
。 Join
還是定位於有現成切片、數組的(畢竟拼接成數組也要時間),並且使用固定方式進行分解的,比如逗號、空格等,侷限比較大。
小結
至於10000個字符串拼接我這裏就不做測試了,大家可以自己試試,看看是不是大同小異的。
從最近的這兩篇文章的分析來看,我們大概可以總結出。
+
連接適用於短小的、常量字符串(明確的,非變量),因爲編譯器會給我們優化。Join
是比較統一的拼接,不太靈活fmt
和buffer
基本上不推薦builder
從性能和靈活性上,都是上佳的選擇。
到這裏就完了嗎?這篇文章是完了,我也該睡覺了。但是字符串高效拼接還沒完,以上並不是終極性能,還可以優化,敬請期待第三篇。