Go 高性能json库比较


概览


在大房间场景下,房间成员列表接口要返回该房间全部成员,要序列化的struct很大(最后返回的序列化后的response大小有1M以上),不以性能见长的官方json库非常吃力。

因为后向兼容性,不能通过加分页参数等手段解决

针对如上大json场景,在此调研几个库,分析性能及替换成本




社区中的一些第三方库


github.com/json-iterator/go (滴滴)


优点是可以比较方便替换官方库,改动成本低

在 Go 1.19 arm64环境下:

官方json库执行了292次,每次执行的平均时间是4062368纳秒(即4.062368 毫秒), 每次操作有57624次内存分配,每次分配了3056902 Byte大小的内存空间

json-iterator看起来并没有比官方库好到哪里..

据说是因为1.13后,官方的json库做了大幅优化,并不比json-iterator/go 库差 (这个库上个月还在更新,如果性能和官方库相差无几,搞不懂存在的意义在哪..)


在 amd64上,同样效果不彰



github.com/buger/jsonparser


性能好,但只有json字符串解析为结构体/map功能,没有将结构体转为json字符串的功能

只能解析JSON字符串,而没法生成JSON(即只有Unmarshal,没有Marshal)

舍弃


github.com/mailru/easyjson


这个package需要预先生成DO NOT EDIT的文件,改动较大




比较


最后选定了 官方库,滴滴的jsoniter,字节的sonic,和ffjson 这几个Go生态较主流的json库,进行序列化性能的比较

benchmark代码见 json-compare

看起来差距并不大..

而根据sonic官方宣传 sonic:基于 JIT 技术的开源全场景高性能 JSON 库

看图上的意思,能比标准库高5倍。 然而测下来并没有

失望之余,看了下sonic的 readme.md

benchmark机器是m1,需要安装Rosetta 2


Mac系统,sonic库会自动回退到标准库?限定了 Linux 系统才能用?

不会,无论是linux还是mac,只要cpu是amd64架构,go版本符合要求,效果都很好,应该是arm架构如果不安装Rosetta 2,会回退到标准库

官方的benchmark用的就是amd64架构的Mac


安装Rosetta 2太麻烦,直接换用amd64的机器:

无论是linux还是mac,只要cpu是amd64架构,效果都出奇的好


使用sonic 将大结构体Encoding为json字符串,1/5于标准库的单次执行时间,1/5于标准库的单次内存空间分配,更令人咋舌的是只有4次内存分配,直接相差4个数量级。。


改造


改造很简单,可以直接替换(json–>sonic)

1
2
3
4
5
6
7
import "github.com/bytedance/sonic"

var data YourSchema
// Marshal
output, err := sonic.Marshal(&data)
// Unmarshal
err := sonic.Unmarshal(output, &data)

有一些特殊case,需要考虑




为什么这样快?



知名项目中的使用


Gin的internal/json已经用了sonic



kube-openapi/pkg/internal/third_party/go-json-experiment/json/ 有一个更详细的性能对比

More performant: JSON serialization is widely used and any bit of extra performance gains will be greatly appreciated.

这句太认同了


相关博客 深入 Go 中各个高性能 JSON 解析库