C# Protocol Buffer 有多快或多轻？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/475794/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How fast or lightweight Is Protocol Buffer?
提问by Hao
Is Protocol Buffer for .NET gonna be lightweight/faster than Remoting(the SerializationFormat.Binary)? Will there be a first class support for it in language/framework terms? i.e. is it handled transparently like with Remoting/WebServices?
.NET 的协议缓冲区是否会比远程处理（SerializationFormat.Binary）轻量级/更快？在语言/框架方面会有一流的支持吗？即它是否像 Remoting/WebServices 一样透明地处理？
采纳答案by Jon Skeet
I very much doubt that it will ever have direct language support or even framework support - it's the kind of thing which is handled perfectly well with 3rd party libraries.
我非常怀疑它是否会有直接的语言支持甚至框架支持——这是一种可以用 3rd 方库完美处理的事情。
My own port of the Java codeis explicit - you have to call methods to serialize/deserialize. (There are RPC stubs which will automatically serialize/deserialize, but no RPC implementation yet.)
我自己的 Java 代码端口是明确的 - 您必须调用方法来序列化/反序列化。（有 RPC 存根会自动序列化/反序列化，但还没有 RPC 实现。）
Marc Gravell's projectfits in very nicely with WCF though - as far as I'm aware, you just need to tell it (once) to use protocol buffers for serialization, and the rest is transparent.
Marc Gravell 的项目非常适合 WCF - 据我所知，您只需要告诉它（一次）使用协议缓冲区进行序列化，其余的都是透明的。
In terms of speed, you should look at Marc Gravell's benchmark page. My code tends to be slightly faster than his, but both are much, much faster than the other serialization/deserialization options in the framework. It should be pointed out that protocol buffers are much more limited as well - they don't try to serialize arbitrary types, only the supported ones. We're going to try to support more of the common data types (decimal, DateTime etc) in a portable way (as their own protocol buffer messages) in future.
在速度方面，您应该查看Marc Gravell 的基准页面。我的代码往往比他的略快，但两者都比框架中的其他序列化/反序列化选项快得多。应该指出的是，协议缓冲区也受到更多限制 - 它们不会尝试序列化任意类型，仅尝试序列化受支持的类型。将来，我们将尝试以可移植的方式（作为它们自己的协议缓冲区消息）支持更多常见数据类型（十进制、日期时间等）。
回答by Marc Gravell
Some performance and size metrics are on this page. I haven't got Jon's stats on there at the moment, just because the page is a little old (Jon: we must fix that!).
此页面上提供了一些性能和大小指标。我目前没有在那里得到 Jon 的统计数据，只是因为页面有点旧（Jon：我们必须解决这个问题！）。
Re being transparent; protobuf-netcan hook into WCF via the contract; note that it plays nicely with MTOM over basic-http too. This doesn't work with Silverlight, though, since Silverlight lacks the injection point. If you use svcutil, you also need to add an attribute to class (via a partial class).
重新透明；protobuf-net可以通过合约挂钩到 WCF；请注意，它也可以通过 basic-http 与 MTOM 很好地配合使用。但是，这不适用于 Silverlight，因为 Silverlight 缺少注入点。如果您使用 svcutil，您还需要向类添加一个属性（通过部分类）。
Re BinaryFormatter (remoting); yes, this has full supprt; you can do this simply by a trivial ISerializableimplementation (i.e. just call the Serializermethod with the same args). If you use protogento create your classes, then it can do it for you: you can enable this at the command line via arguments (it isn't enabled by default as BinaryFormatterdoesn't work on all frameworks [CF, etc]).
重新 BinaryFormatter（远程处理）；是的，这有充分的支持；您可以简单地通过一个简单的ISerializable实现来做到这一点（即，只需Serializer使用相同的参数调用该方法）。如果您protogen用来创建类，那么它可以为您完成：您可以通过参数在命令行中启用它（默认情况下它不启用，因为BinaryFormatter不适用于所有框架 [CF 等]）。
Note that for very small objects (single instances, etc) on local remoting (IPC), the raw BinaryFormatterperformance is actually better - but for non-trivial graphs or remote links (network remoting) protobuf-net can out-perform it pretty well.
请注意，对于本地远程处理 (IPC) 上的非常小的对象（单个实例等），原始BinaryFormatter性能实际上更好 - 但对于非平凡的图形或远程链接（网络远程处理）protobuf-net 可以很好地胜过它。
I should also note that the protocol buffers wire format doesn't directly support inheritance; protobuf-net can spoof this (while retaining wire-compatibility), but like with XmlSerializer, you need to declare the sub-classes up-front.
我还应该注意到，protocol buffers 线格式不直接支持继承；protobuf-net 可以欺骗这一点（同时保留线兼容性），但与 XmlSerializer 一样，您需要预先声明子类。
Why are there two versions?
为什么有两个版本？
The joys of open source, I guess ;-p Jon and I have worked on joint projects before, and have discussed merging these two, but the fact is that they target two different scenarios:
开源的乐趣，我猜；-p Jon 和我之前曾参与过联合项目，并讨论过合并这两个项目，但事实是他们针对两种不同的场景：
- dotnet-protobufs(Jon's) is a port of the existing java version. This means it has a very familiar API for anybody already using the java version, and it is built on typical java constructs (builder classes, immutable data classes, etc) - with a few C# twists.
- protobuf-net(Marc's) is a ground-up re-implementation following the same binary format (indeed, a critical requirement is that you can interchange data between different formats), but using typical .NET idioms:
- mutable data classes (no builders)
- the serialization member specifics are expressed in attributes (comparable to
XmlSerializer,DataContractSerializer, etc)
- dotnet-protobufs(Jon's) 是现有 Java 版本的一个端口。这意味着对于已经在使用 java 版本的任何人来说，它都有一个非常熟悉的 API，并且它构建在典型的 java 结构（构建器类、不可变数据类等）上 - 有一些 C# 曲折。
- protobuf-net（Marc 的）是遵循相同二进制格式（实际上，一个关键要求是您可以在不同格式之间交换数据）的重新实现，但使用典型的 .NET 习语：
- 可变数据类（无构建器）
- 串行化构件的细节在属性被表达（媲美
XmlSerializer，DataContractSerializer等）
If you are working on java and .NET clients, Jon's is probably a good choice for the familiar API on both sides. If you are pure .NET, protobuf-net has advantages - the familiar .NET style API, but also:
如果您正在处理 java 和 .NET 客户端，Jon's 可能是双方熟悉的 API 的不错选择。如果你是纯 .NET，protobuf-net 有优势——熟悉的 .NET 风格的 API，还有：
- you aren't forcedto be contract-first (although you can, and a code-generator is supplied)
- you can re-use your existing objects (in fact,
[DataContract]and[XmlType]classes can often be used without any changes at all) - it has full support for inheritance (which it achieves on the wire by spoofing encapsulation) (possibly unique for a protocol buffers implementation? note that sub-classes have to be declared in advance)
- it goes out of its way to plug into and exploit core .NET tools (
BinaryFormatter,XmlSerializer, WCF,DataContractSerializer) - allowing it to work directly as a remoting engine. This would presumably be quite a big split from the main java trunk for Jon's port.
- 您不会被迫以合同为先（尽管您可以，并且提供了代码生成器）
- 你可以重新使用现有的对象（其实，
[DataContract]并且[XmlType]通常可以在没有任何所有的变化使用的类） - 它完全支持继承（它通过欺骗封装在网络上实现）（对于协议缓冲区实现可能是唯一的？注意子类必须提前声明）
- 它超出其方式插头插入和利用核心.NET工具（
BinaryFormatter，XmlSerializer，WCFDataContractSerializer） -允许其直接作为远程发动机工作。对于 Jon 的端口，这可能与主 Java 主干的分离相当大。
Re merging them; I think we'd both be open to it, but it seems unlikely you'd want both feature sets, since they target such different requirements.
重新合并它们；我认为我们都对它持开放态度，但您似乎不太可能同时需要这两个功能集，因为它们针对不同的需求。
