协议缓冲区的速度有多快或多快？

Question

.NET的协议缓冲区是否比Remoting（SerializationFormat.Binary）更轻/更快？是否会以语言/框架术语为其提供一流的支持？即它是否像Remoting / WebServices一样透明地处理？

Answer 1

我非常怀疑它是否会提供直接的语言支持甚至框架支持 - 这是与第三方库完美配合的事情。

My own port of the Java code是显式的 - 您必须调用序列化/反序列化的方法。 （有RPC存根将自动序列化/反序列化，但还没有RPC实现。）

Marc Gravell's project非常适合WCF - 据我所知，你只需告诉它（一次）使用协议缓冲区进行序列化，其余部分是透明的。

就速度而言，你应该看看Marc Gravell's benchmark page。我的代码往往比他的代码略快，但两者都比框架中的其他序列化/反序列化选项快得多。应该指出的是，协议缓冲区也受到更多限制 - 它们不会尝试序列化任意类型，只有受支持的类型。我们将来会尝试以可移植的方式（作为自己的协议缓冲消息）支持更多常见数据类型（十进制，DateTime等）。

Answer 2

某些效果和尺寸指标位于this page。我目前还没有Jon的统计数据，只是因为页面有点旧（Jon：我们必须解决这个问题！）。

重新透明; protobuf-net可以通过合同挂钩到WCF;请注意，它与MTOM相比也可以在basic-http上播放。但是，这不适用于Silverlight，因为Silverlight缺少注入点。如果使用svcutil，还需要向类添加属性（通过部分类）。

Re BinaryFormatter（远程处理）;是的，这完全支持;你可以通过一个简单的ISerializable实现来做到这一点（即只需使用相同的args调用Serializer方法）。如果您使用protogen创建类，那么它可以为您执行：您可以通过参数在命令行启用它（默认情况下不启用它，因为BinaryFormatter不起作用所有框架[CF等]。

请注意，对于本地远程处理（IPC）上的非常小的对象（单个实例等），原始BinaryFormatter性能实际上更好 - 但对于非平凡的图形或远程链接（网络远程处理）protobuf-net可以很好地表现出来。

我还应该注意，协议缓冲线格式不直接支持继承; protobuf-net可以欺骗这一点（同时保持线路兼容性），但与XmlSerializer一样，你需要预先声明子类。

---

为什么有两个版本？

开源的乐趣，我想; -p Jon和我之前曾参与过联合项目，并讨论了合并这两个项目，但事实是它们针对两种不同的场景：

• dotnet-protobufs（Jon's）是现有java版本的端口。这意味着它已经为任何已经使用java版本的人提供了一个非常熟悉的API，它建立在典型的java构造（构建器类，不可变数据类等）上 - 只有几个C＃曲折。
• protobuf-net（Marc's）是一种基于相同二进制格式的重新实现（实际上，关键要求是您可以在不同格式之间交换数据），但使用典型的.NET习惯用法：
  • 可变数据类（无构建者）
  • 序列化成员细节以属性表示（与XmlSerializer，DataContractSerializer等相当）

如果您正在使用Java和.NET客户端，那么Jon's可能是双方熟悉的API的不错选择。如果你是纯.NET，protobuf-net有优势 - 熟悉的.NET风格的API，还有：

• 你不是强制合同优先（尽管你可以，并提供代码生成器）
• 您可以重复使用现有对象（实际上，通常可以使用[DataContract]和[XmlType]类，而无需进行任何更改。
• 它完全支持继承（它通过欺骗封装在线上实现）（对于协议缓冲区实现可能是唯一的？请注意，必须提前声明子类）
• 它不遗余力地插入和利用核心.NET工具（BinaryFormatter，XmlSerializer，WCF，DataContractSerializer） - 允许它直接作为远程引擎工作。这可能与Jon的端口的主要java主干大相径庭。

重新合并他们;我认为我们都对它持开放态度，但你似乎不太可能想要这两个功能集，因为它们针对的是这些不同的要求。