协议缓冲区如何比XML和JSON更快？

Question

最近，我开始在工作中阅读和使用gRPC。gRPC在内部使用协议缓冲区作为IDL，我一直在阅读协议缓冲区比JSON和XML更好、更快的性能。

我不明白的是-他们是怎么做到的？与XML和JSON相比，协议缓冲区中的哪些设计实际上使它们的执行速度更快？

Answer 1

数据的字符串表示：

• 需要文本编码/解码(这可能很便宜，但仍然是额外的一步)
• 需要复杂的解析代码，特别是如果存在“必须允许空白”之类的对人友好的规则。
• 通常需要更多的带宽--因此需要更多的实际有效负载--这是因为嵌入了诸如名称之类的东西，并且(同样)必须处理对人友好的表示(例如，如何标记语法)。
• 通常需要大量用于成员查找等的中间字符串实例。

基于文本的序列化程序和基于二进制的序列化程序都可以是快速和高效的(或慢和可怕的).只是:二进制序列化器有其优势。这意味着“好”二进制序列化程序通常比“好”基于文本的序列化程序更快。

让我们比较一个整数的基本示例：

杰森：

{"id":42}

9字节，如果我们假设ASCII或UTF-8编码，没有空格。

xml：

<id>42</id>

11字节，如果我们假设ASCII或UTF-8编码，没有空白-没有名称空间噪音类似的名称空间。

原始人：

0x08 0x2a

2字节

现在想象一下编写一个通用的xml或json解析器，以及您需要在文本层处理的所有歧义和场景，然后您需要将文本令牌"id"映射到一个成员，然后您需要在"42"上进行整数解析。在protobuf中，有效载荷较小，加上数学简单，成员查找是一个整数(所以:适合于非常快的switch/jump)。

Answer 2

虽然二进制协议在理论上具有优势，但在实践中，它们在性能上可能会输给JSON或其他具有文本表示的协议，具体取决于实现。

高效的JSON解析器(如RapidJSON或jsoniter-scala )以每字节2-8周期的速度解析大多数JSON示例。它们的序列化效率甚至更高，除非在序列化速度下降到每字节16-32个周期时，使用浮点的数字等边缘情况除外。

但是对于大多数没有很多浮点数或加倍速度的域来说，它们的速度与最好的二进制序列化程序是相当有竞争力的。请参阅jsoniter分析和序列化与ProtoBuf和Scala库相同的基准测试结果：

https://github.com/dkomanov/scala-serialization/pull/8

Answer 3

我不得不说，二进制协议将是，通常情况下，总是在性能上优于基于文本的协议。哈，您不会发现很多(或任何)视频流应用程序使用JSON来表示帧数据。然而，任何设计不佳的数据结构在被解析时都会遇到困难。我从事过许多通信项目，将基于文本的协议替换为“二进制协议”。