java - 高性能序列化 : Java vs Google Protocol Buffers vs . ..？

Question

对于我正在考虑为即将到来的项目做的一些缓存，我一直在考虑 Java 序列化。即，应该使用它吗？

现在我在过去的几年中出于各种原因编写了自定义序列化和反序列化(Externalizable)。如今，互操作性已成为一个更大的问题，我可以预见到需要与 .Net 应用程序交互，因此我考虑使用独立于平台的解决方案。

有没有人有过高性能使用 GPB 的经验？它在速度和效率方面与 Java 的原生序列化相比如何？或者，还有其他值得考虑的方案吗？

Answer 1

我没有在速度方面将 Protocol Buffers 与 Java 的 native 序列化进行比较，但对于互操作性，Java 的 native 序列化是一个严重的禁忌。在大多数情况下，它在空间方面也不会像 Protocol Buffer 那样有效。当然，它在可以存储的内容和引用等方面更加灵活。Protocol Buffers 非常擅长于它的用途，并且当它满足您的需要时它很棒 - 但由于互操作性存在明显的限制(和其他东西)。

我最近发布了一个用 Java 和 .NET 编写的 Protocol Buffers 基准测试框架。 Java 版本位于 main Google project (在 benchmarks directory 中)，.NET 版本在 my C# port project 中.如果您想将 PB 速度与 Java 序列化速度进行比较，您可以编写类似的类并对其进行基准测试。不过，如果您对互操作感兴趣，我真的不会再考虑原生 Java 序列化(或 .NET 原生二进制序列化)。

除了Protocol Buffers之外，还有其他可互操作的序列化选项 - Thrift , JSON和 YAML浮现在脑海中，毫无疑问还有其他人。

编辑:好的，由于互操作不是那么重要，因此值得尝试列出您希望从序列化框架中获得的不同品质。您应该考虑的一件事是版本控制——这是 PB 旨在处理好的另一件事，无论是向后还是向前(所以新软件可以读取旧数据，反之亦然)——当然，当你坚持建议的规则时 :)

在尝试对 Java 性能与 native 序列化保持谨慎时，如果发现 PB 更快，我真的不会感到惊讶。如果您有机会，请使用服务器虚拟机 - 我最近的基准测试显示服务器虚拟机在序列化和反序列化示例数据方面的速度是 两倍以上。我认为 PB 代码非常适合服务器 VM 的 JIT :)

正如示例性能数据，序列化和反序列化两条消息(一条 228 字节，一条 84750 字节)我使用服务器 VM 在笔记本电脑上获得了这些结果:

Benchmarking benchmarks.GoogleSize$SizeMessage1 with file google_message1.dat Serialize to byte string: 2581851 iterations in 30.16s; 18.613789MB/s Serialize to byte array: 2583547 iterations in 29.842s; 18.824497MB/s Serialize to memory stream: 2210320 iterations in 30.125s; 15.953759MB/s Deserialize from byte string: 3356517 iterations in 30.088s; 24.256632MB/s Deserialize from byte array: 3356517 iterations in 29.958s; 24.361889MB/s Deserialize from memory stream: 2618821 iterations in 29.821s; 19.094952MB/s Benchmarking benchmarks.GoogleSpeed$SpeedMessage1 with file google_message1.dat Serialize to byte string: 17068518 iterations in 29.978s; 123.802124MB/s Serialize to byte array: 17520066 iterations in 30.043s; 126.802376MB/s Serialize to memory stream: 7736665 iterations in 30.076s; 55.93307MB/s Deserialize from byte string: 16123669 iterations in 30.073s; 116.57947MB/s Deserialize from byte array: 16082453 iterations in 30.109s; 116.14243MB/sDeserialize from memory stream: 7496968 iterations in 30.03s; 54.283176MB/s Benchmarking benchmarks.GoogleSize$SizeMessage2 with file google_message2.dat Serialize to byte string: 6266 iterations in 30.034s; 16.826494MB/s Serialize to byte array: 6246 iterations in 30.027s; 16.776697MB/s Serialize to memory stream: 6042 iterations in 29.916s; 16.288969MB/s Deserialize from byte string: 4675 iterations in 29.819s; 12.644595MB/s Deserialize from byte array: 4694 iterations in 30.093s; 12.580387MB/s Deserialize from memory stream: 4544 iterations in 29.579s; 12.389998MB/s Benchmarking benchmarks.GoogleSpeed$SpeedMessage2 with file google_message2.dat Serialize to byte string: 39562 iterations in 30.055s; 106.16416MB/s Serialize to byte array: 39715 iterations in 30.178s; 106.14035MB/s Serialize to memory stream: 34161 iterations in 30.032s; 91.74085MB/s Deserialize from byte string: 36934 iterations in 29.794s; 99.98019MB/s Deserialize from byte array: 37191 iterations in 29.915s; 100.26867MB/s Deserialize from memory stream: 36237 iterations in 29.846s; 97.92251MB/s 

“速度”与“大小”是生成的代码是否针对速度或代码大小进行了优化。 (两种情况下的序列化数据是相同的。“size”版本是为您定义了很多消息并且不想为代码占用大量内存的情况提供的。)

如您所见，对于较小的消息，它可以非常快速 - 每毫秒序列化或反序列化超过 500 条小消息。即使有 87K 条消息，每条消息也只需要不到一毫秒的时间。