performance - Protocol Buffers 和 Avro 中 ZigZag 编码背后的原因是什么？

Question

ZigZag 需要大量开销来写入/读取数字。实际上，我很惊讶地发现它不仅按原样写入 int/long 值，而且还进行了很多额外的加扰。甚至还涉及到一个循环: https://github.com/mardambey/mypipe/blob/master/avro/lang/java/avro/src/main/java/org/apache/avro/io/DirectBinaryEncoder.java#L90

我似乎无法在 Protocol Buffers 文档或 Avro 文档中找到，或者自己推理，这样的扰乱数字有什么好处？为什么编码后正负数交替比较好？

为什么它们不只是按照小端、大端、网络顺序编写，只需要将它们读入内存并可能反转位端？我们按绩效付费买什么？

Answer 1

它是一个可变长度的 7 位编码。编码值的第一个字节将其高位设置为 0，后续字节将其设置为 1。解码器可以通过这种方式得知使用了多少字节来对值进行编码。无论机器架构如何，字节顺序始终是小端字节序。

这是一种编码技巧，允许根据需要写入尽可能少的字节来对值进行编码。因此，值介于 -64 和 63 之间的 8 字节长仅占用一个字节。这是很常见的，long 提供的范围在实践中很少使用。

设计目标是在没有 gzip 式压缩方法开销的情况下紧密打包数据。也用于.NET Framework 。编码/解码该值所需的处理器开销是无关紧要的。它已经比压缩方案低得多，只占 I/O 成本的很小一部分。