提高序列化性能:文本与二进制格式
如果性能是一个问题,我是否应该更喜欢二进制序列化而不是 ascii/文本序列化?
有人用大量数据测试过吗?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
如果性能是一个问题,我是否应该更喜欢二进制序列化而不是 ascii/文本序列化?
有人用大量数据测试过吗?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(3)
我使用 boost.serialization 来存储表示查找表的矩阵和向量以及
一些内存大小约为 200MByte 的元数据(字符串)。 IIRC 用于加载
将文本存档从磁盘写入内存需要 3 分钟,而使用二进制存档则需要 4 秒
在WinXP上。
I used boost.serialization to store matrices and vectors representing lookup tables and
some meta data (strings) with an in memory size of about 200MByte. IIRC for loading from
disk into memory it took 3 minutes for the text archive vs. 4 seconds using the binary archive
on WinXP.
针对涉及加载包含大量(数千个)嵌套存档类的大型类的问题对其进行了基准测试。
要更改格式,请使用存档流
而不是
加载(二进制)存档的代码如下所示:
上述代码片段的优化 gcc 构建的文件和 walltime 为:
这是来自固态驱动器,没有任何流压缩。
因此,速度的提升比文件大小所建议的要大,并且使用二进制文件还可以获得额外的好处。
Benchmarked it for a problem involving loading a large class containing lots (thousands) of nested archived classes.
To change the format, use archive streams
instead of
The code for loading the (binary) archive looks like:
The files and walltimes for an optimised gcc build of the above code snippet are:
This is from a solid state drive, without any stream compression.
So the gain in speed is larger than the file size would suggest, and you get an additional bonus using binary.
protobuf - Protocol Buffers
如果性能是一个问题 http://code.google.com/p/protobuf-net/" rel="nofollow noreferrer">来自 .Net 的“协议缓冲区”
I suggest you look into protobuf - Protocol Buffers if performance is an issue
"Protocol Buffers" from .Net