本文探讨了ProtoBuf在处理大量嵌套Message时的效率和空间开销问题。通过分析ProtoBuf的源码，揭示了ProtoBuf对`repeated message`和`repeated raw`类型的内存管理差异，指出在`repeated message`中每次ADD操作都会NEW一次，导致性能下降。作者建议调整PROTO文件以优化应用协议，以降低时间开销。经过修改，测试结果显示时间开销减少了约1/10。
当前项目中普遍用到GOOGLE 的一个开源大作PROTOBUF，把它作为网络应用层面的传输协议，至于它的诸多优势这里不作多说了！直接入正题！
前几日在PROTOBUF上面有严重的效率和空间开销的问题，没想到这两大难题一下子都来了，来得真是“迅雷不及掩耳之势”！跟踪后发现问题出在了“嵌套的MESSAGE个数过多，时间开销基本上全花在了ADD message上面”，例如：
message B{
标记 类型 变量 ＝ 序列号；
...
}
message A{
repeated B f = 1;
}
A a;
这里message A中有上百万个message B，时间开销基本花在了 a.add_f()上面，而且空间上面开销也比较大。
针对这个头疼的问题，头这几天也在着急，项目都进行到这儿出了这等问题!之前我一直怀疑我们的策略问题，这几天在头儿的指示下，研究了一下PROTOBUF的源码，了解其中部分实现体制。这里简单地跟大家分享一下，大家尽管把砖头拍过来，嘿嘿！^_^
protobuf针对required 标记的字段分了两类，对每类都有相应的处理方式。其一：MESSAGE STRING；其二：非MESSAGE 和STRING，即原始数据类型，如INT32 INT64 FLOAT 等。我们把它们称为：repeated message(或者string)和repeated raw(原始数据类型)两种。PROTOBUF针对前者对内存的管理是，每次A
最低0.47元/天 解锁文章
扫一扫
1311
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
