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

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

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

我自己的Java代码端口是显式的 - 您必须调用序列化/反序列化的方法.(有RPC存根会自动序列化/反序列化,但还没有RPC实现.)

Marc Gravell的项目非常适合WCF - 据我所知,你只需要告诉它(一次)使用协议缓冲区进行序列化,其余的是透明的.

在速度方面,你应该看看Marc Gravell的基准页面.我的代码往往比他的代码略快,但两者都比框架中的其他序列化/反序列化选项快得多.应该指出的是,协议缓冲区也受到更多限制 - 它们不会尝试序列化任意类型,只有受支持的类型.我们将来会尝试以可移植的方式(作为自己的协议缓冲区消息)支持更多常见数据类型(十进制,日期时间等).

此页面上包含一些性能和大小指标.我目前还没有Jon的统计数据,只是因为页面有点旧(Jon:我们必须解决这个问题!).

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

Re BinaryFormatter(remoting); 是的,这完全支持; 你可以简单地通过一个简单的ISerializable实现来做到这一点(即只Serializer使用相同的args 调用方法).如果您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主干大相径庭.

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