先说结论
从易用性、性能、内存占用、编码后大小等几个方面综合考虑 ProtoBuf 胜出。
Gob 从性能和 I/O 带宽占用上都和 ProtoBuf 差不多,唯一劣势是编解码时内存占用较多。考虑到不用再写 IDL 带来的易用性,如果整个系统内不存在使用除 Go 以外其他语言的服务,Gob 是更合适的选择。
json | msgp | gob | pb | flatbuffers | |
---|---|---|---|---|---|
易用性 | 好 | 好 | 好 | 一般 | 极差 |
性能 | 差 | 差 | 好 | 好 | 好 |
编解码内存占用 | 一般 | 差 | 差 | 好 | 差 |
编码后大小 | 差 | 差 | 好 | 好 | 差 |
成熟度 | 好 | 一般 | 较好 | 好 | 一般 |
测试场景
限制单核单线程场景,使用本地机器进行测试。
使用对象为 10 个字段对象,包括 string、int32、slice、map 等多种类型,且存在嵌套关系。
type Layer10 struct {
IntField int32
StringField string
SliceField []int32
MapField map[string]int32
Field5 int32
Field6 string
Field7 []int32
Field8 map[string]int32
Field9 int32
Field10 string
Layer10 *Layer10
}
主要验证 json、gob、msgp、pb、flatbuffers 这 5 种序列化方案。
场景1:层数逐渐增长
性能
这里不对CPU利用率做分析,原因是编解码属于纯计算密集型场景,每一种序列化方式都能跑满CPU。我们应该关注同等CPU性能下,序列化的效率。下面分别测试编解码混合、仅编码和仅解码的效率。
编解码混合
设定层级数从1层到100层递增,使用5种序列化方式进行编码+解码。
可以看出,在对象简单时(嵌套层级不超过5层),gob的性能不是很好,甚至比json更差;但在对象复杂度很高时,gob的性能优势就体现出来。
pb的性能略好于gob,二者的增长斜率基本一致。在应对复杂对象场景时,GOB性能要比JSON好一倍以上。
性能排名(>表示优于):FLAT > PB > GOB > MSGP > JSON
仅编码
JSON 的编码效率并不低,甚至能和 GOB 和 PB 保持在同一水平线上。
仅解码
解码效率拉开差距,JSON 解码性能很差,GOB 和 PB 较好,GOB 略低于 PB。
内存使用率
在序列化过程中,gob 需要消耗较多内存。而 pb 一直保持较低内存消耗
内存使用排序(>表示优于):PB > JSON > FLAT > MSGP >GOB
编码后大小
编码后,pb 和 gob 的长度都较小,基本不分伯仲。其他三种表现一般。
编码后大小排序(>表示优于):GOB > PB > FLAT > MSGP > JSON
以下是不同数量级时的性能表现:
# 层级为1时
Layer-1-Size-1-JSON 1000 3887 ns/op 1384 B/op 34 allocs/op
Layer-1-Size-1-GOB 1000 23707 ns/op 13270 B/op 333 allocs/op
Layer-1-Size-1-PB 1000 1594 ns/op 1000 B/op 30 allocs/op
Layer-1-Size-1-MSGP 1000 4139 ns/op 2040 B/op 59 allocs/op
Layer-1-Size-1-FLAT 1000 6.708 ns/op 1 B/op 0 allocs/op
# 层级为10时
Layer-10-Size-1-JSON 1000 39244 ns/op 11592 B/op 256 allocs/op
Layer-10-Size-1-GOB 1000 40830 ns/op 27202 B/op 623 allocs/op
Layer-10-Size-1-PB 1000 17232 ns/op 9280 B/op 264 allocs/op
Layer-10-Size-1-MSGP 1000 32549 ns/op 15208 B/op 431 allocs/op
Layer-10-Size-1-FLAT 1000 20.79 ns/op 13 B/op 0 allocs/op
# 层级为100时
Layer-100-Size-1-JSON 1000 351715 ns/op 111428 B/op 2422 allocs/op
Layer-100-Size-1-GOB 1000 183746 ns/op 172531 B/op 3509 allocs/op
Layer-100-Size-1-PB 1000 162784 ns/op 92208 B/op 2604 allocs/op
Layer-100-Size-1-MSGP 1000 315320 ns/op 172416 B/op 4125 allocs/op
Layer-100-Size-1-FLAT 1000 88.75 ns/op 120 B/op 1 allocs/op
场景2:切片长度逐渐增长
设定一个[]Layer10
,Layer10 只有一层,不做嵌套。切片中对象的数量逐渐增长
性能
与层级增长的情况一致,在对象简单时(列表长度不超过 15 个时),gob 的性能不是很好,甚至比 json 更差;但在对象复杂度很高时,gob 的性能优势才能体现出来。
性能排名:FLAT > PB > GOB > MSGP > JSON
内存使用率
结论同场景 1 一致
编码后大小
结论同场景 1 一致
不同数量级时的性能表现:
# 层级为1时
Layer-1-Size-1-JSON 1000 3903 ns/op 1384 B/op 34 allocs/op
Layer-1-Size-1-GOB 1000 23681 ns/op 13267 B/op 333 allocs/op
Layer-1-Size-1-PB 1000 1614 ns/op 1000 B/op 30 allocs/op
Layer-1-Size-1-MSGP 1000 4010 ns/op 2040 B/op 59 allocs/op
Layer-1-Size-1-FLAT 1000 7.458 ns/op 1 B/op 0 allocs/op
# 层级为10时
Layer-1-Size-10-JSON 1000 37965 ns/op 11592 B/op 256 allocs/op
Layer-1-Size-10-GOB 1000 40962 ns/op 27205 B/op 623 allocs/op
Layer-1-Size-10-PB 1000 16340 ns/op 9280 B/op 264 allocs/op
Layer-1-Size-10-MSGP 1000 31643 ns/op 15208 B/op 431 allocs/op
Layer-1-Size-10-FLAT 1000 14.50 ns/op 13 B/op 0 allocs/op
# 层级为100时
Layer-1-Size-100-JSON 1000 388890 ns/op 111420 B/op 2422 allocs/op
Layer-1-Size-100-GOB 1000 190858 ns/op 172533 B/op 3509 allocs/op
Layer-1-Size-100-PB 1000 166676 ns/op 92208 B/op 2604 allocs/op
Layer-1-Size-100-MSGP 1000 309114 ns/op 172416 B/op 4125 allocs/op
Layer-1-Size-100-FLAT 1000 85.62 ns/op 120 B/op 1 allocs/op
分析
不管是嵌套层级数增加还是切片长度增加,整体趋势改变不大。各序列化方案的差异会随着对象复杂度的增加而拉大。
单从性能角度考虑,flatbuffers 的性能很好,原因是 flatbuffers 是直接向 ByteBuffer 里塞字节流的,就省掉了反射的步骤。但这样就牺牲了易用性。编写代码时,连set字段值的顺序都有非常严格的要求。这对研发的要求太高了,可能会导致很多问题。像这种极端难用的,除非有非常迫切的性能需要,否则肯定是不建议使用的。
综合考虑各方面因素,ProtoBuf 脱颖而出,但唯一不好的就是要写 IDL。是否可以通过二次开发或者包装工具的方式来抹平 IDL 带来的缺点。
Gob 从性能和 I/O 带宽占用上都和 ProtoBuf 差不多,唯一劣势是编解码时内存占用较多。考虑到不用再写IDL带来的易用性,在「只使用 Go 语言」的背景下,Gob 是更合适的选择。