寫項目一直需要進行序列化,聽到了,也看到了很多同學老師對各個golang的<code>json</code>庫進行測評。那本人為什麼還要繼續進行這一次測評呢?
因為實踐過的知識最有說服力,也是屬于自己的,我也希望看到本博文的同學老師可以修改和執行測評的代碼執行一遍,我相信會有不一定的體會。
本次測評我選擇了類庫有:
序号
類庫
位址
備注
1
encoding/json
Golan
2
easyjson
github.com/mailru/easyjson
3
ffjson
4
iterator/json
github.com/json-iterator/go
主要是針對上述的類型進行,本人采用了對不同的類庫使用不同的結構體(僅僅是結構體名稱不同,字段順序和類型一樣)。
環境為MacBook Pro(Core i5處理器/8GB記憶體)go1.8.3 darwin/amd64
bench代碼如下:
執行指令:
測評結果;
哪一個類庫最快?
答:是測評類庫中最快的。速度:easyjson => iterator => encoding/json => ffjson
是否存在坑?
答:<code>easyjson</code>有一個坑,從代碼中可以看到<code>Benchmark_EASYJSON_STD_*</code>的方法,是因為easyjson生成的代碼中已經包含了<code>MarshalJSON</code>和<code>UnmarshalJSON</code>方法,那麼隻要對這些結構體執行<code>json.marshalJSON</code>和<code>json.UnmarshalJSON</code>都會預設調用easyjson生成的方法。本人運作多次,都會發現調用easyjson生成的<code>MarshalJSON</code>方法比标準庫中的慢一些達到50%左右,但是調用<code>easyjson</code>生成的<code>UnmarshalJSON</code>比标準庫的快一些大概20%。
如何選擇?
答:<code>easyjson</code>速度雖然比較快,但也是存在一些不适合的場景,比如如果需要對<code>interface</code>接口進行序列化時候。是以建議采用<code>easyjson</code>與标準庫結合。
本文轉自 夢朝思夕 51CTO部落格,原文連結:http://blog.51cto.com/qiangmzsx/2070603