Protocol Buffer有多快或多轻量级？

Question

.NET的协议缓冲区会比远程处理( SerializationFormat.Binary)更轻量级/更快吗？在语言/框架方面会有对它的一流支持吗？也就是说，它是否像远程处理/WebServices一样透明地处理？

Answer 1

我非常怀疑它是否会有直接的语言支持，甚至是框架支持--这是一种可以通过第三方库很好地处理的东西。

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

Marc Gravell's project非常适合使用WCF --据我所知，你只需要告诉它(一次)使用protocol buffer进行序列化，剩下的都是透明的。

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

Answer 2

一些性能和大小指标在this page上。我现在还没有Jon的统计数据，只是因为页面有点旧(Jon:我们必须解决这个问题！)

Re是透明的；protobuf-net可以通过契约连接到WCF；请注意，它在basic-http上也能很好地处理MTOM。然而，这不适用于Silverlight，因为Silverlight缺少注入点。如果您使用svcutil，您还需要向class添加一个属性(通过一个分部类)。

Re BinaryFormatter (remoting)；是的，这是完全支持的；你可以通过一个简单的ISerializable实现来做到这一点(即只需使用相同的参数调用Serializer方法)。如果你使用protogen来创建你的类，那么它可以帮你做到这一点:你可以通过参数在命令行中启用它(它在默认情况下是不启用的，因为BinaryFormatter并不是在所有框架上都能工作，CF等等)。

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

我还应该注意到protocol buffers有线格式并不直接支持继承；protobuf-net可以欺骗这一点(同时保持有线兼容性)，但与XmlSerializer一样，您需要预先声明子类。

为什么有两个版本？

开源的乐趣，我猜;-p Jon和我之前在联合项目中工作过，并讨论过合并这两个项目，但事实是他们针对两个不同的场景：

• dotnet-protobufs (Jon's)是现有java版本的一个端口。这意味着对于已经使用builders)
• the版本的任何人来说，它都有一个非常熟悉的API，并且它是建立在典型的C#构造(构建器类、不可变的数据类等)的基础上的--有一些twists.
• protobuf-net (Marc的)是遵循相同的二进制格式(实际上，关键的要求是您可以在不同的格式之间交换数据)的基础上的重新实现，但是使用典型的.NET习惯用法：
  • 可变数据类(没有java序列化成员的细节被表示在属性中(与XmlSerializer，DataContractSerializer，etc)

​

如果您使用的是java和.NET客户端，那么对于两端熟悉的API，Jon可能是一个很好的选择。如果你是纯粹的.NET，protobuf-net有优势--熟悉的.NET风格的API，而且：

协议缓冲区( supplied)

• you
• )可以重用您现有的对象(事实上，[DataContract]和[XmlType]类通常可以在没有任何更改的情况下使用)
• 它完全支持继承(它通过欺骗封装在网络上实现)(对于 buffers实现可能是唯一的？注意，子类必须事先声明)
  • 它不遗余力地插入和利用核心.NET工具(BinaryFormatter，XmlSerializer，WCF，DataContractSerializer) -允许它直接作为远程处理引擎工作。这可能与Jon的端口的主要java主干有很大的不同。

重新合并它们；我认为我们都会对此持开放态度，但似乎不太可能同时需要两个功能集，因为它们针对的是如此不同的需求。