Google Protocol Buffers 中的必填字段编码效率更高吗？答案

【问题标题】：Are required fields encoded more efficiently in Google Protocol Buffers?Google Protocol Buffers 中的必填字段编码效率更高吗？
【发布时间】：2014-09-05 06:12:18
【问题描述】：

我的结构包含一个重复的字段，它本身就是一个小结构，仅包含两个整数：

   message Bin {
     optional int32 slot = 1;
     optional int32 count = 2;
   }

   message Histogram {
     repeated Bin bin = 1; // Might be about 200 - 400 bins.
   }

如果我将slot 和count 定义为required，Bin 的编码效率会更高吗？

我认为如果发生不太可能的变化，我可以完全重新定义Bin 消息并将Histogram 修改为

repeated Bin2 bin2 = 2;

（repeated 字段可以删除）

【问题讨论】：

不，每个字段之前都有一个Field_Number/Field_Type字段，后面跟着数据

标签： protocol-buffers

【解决方案1】：

不，基本上； encoding details are here，但无论是 optional 还是 required，slot/count 的 eash 将是一个 varint 字段标题/线型组合，后跟一个 varint 值。 optional vs required 不会改变格式：它只是改变是否需要值。有趣的是，只有一个值的 repeated 值与存在的 optional / required 值之间实际上也没有区别。这种确实改变的唯一时间是重复原语的“打包”编码。如果您有很多个，实际上可以从 1 个或 2 个打包数组中获得更有效的数据：

message Histogram {
  repeated int32 slots = 1 [packed=true];
  repeated int32 counts = 2 [packed=true];
}

上述方法不太方便，但在线上效率更高。你当然可以用一个双长度数组做同样的事情：

message Histogram {
  repeated int32 slotsAndCounts = 1 [packed=true];
}

一个包含 5 个项目的正常重复字段的作用如下：

字段头，值，字段头，值，字段头，值，字段头，值，字段头，值

一个包含 5 个项目的 packed 重复字段的作用如下：

字段头、长度、值、值、值、值、值

【讨论】：