blocks|key|3071418|text|protocol+buffers是为线路设计的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3071419|非常小的消息大小-一个方面是非常有效的可变大小整数representation.|3071420|Very快速解码-它是一个二进制protocol.|unordered-list-item|3071421|
|3071422|protobuf生成用于编码和解码消息的超级高效的C%2B%2B+-提示:如果你将所有可变整数或静态大小的项都编码到其中，它将以确定的速度进行编码和解码。|3071423|3071424|它提供了一个非常丰富的数据模型--有效地编码非常复杂的数据结构。|3071425|3071426|JSON只是文本，需要经过解析的。提示:将一个“十亿”整数编码到其中将需要相当多的字符:十亿=+12个字符(长刻度)，在二进制中它适合一个uint32_t现在尝试编码一个双精度值怎么样？那就糟糕得多了。|offset|length|style|BOLD|3071427|entityMap^0|0|0|0|0|0|0|0|0|D|3|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$]]|$1|G|3|H|5|6|7|Z|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|10|8|@]|9|@]|A|$]]|$1|K|3|H|5|6|7|11|8|@]|9|@]|A|$]]|$1|L|3|M|5|F|7|12|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@$Q|15|R|16|S|T]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

protocol buffers is designed for the wire: 

<ol>
<li>very small message size - one aspect is very efficient variable sized integer representation.</li>
<li>Very fast decoding - it is a binary protocol.</li>
<li>protobuf generates super efficient C++ for encoding and decoding the messages -- hint: if you encode all var-integers or static sized items into it it will encode and decode at deterministic speed.</li>
<li>It offers a VERY rich data model -- efficiently encoding very complex data structures.</li>
</ol>

JSON is just text and it needs to be parsed. hint: encoding a "billion" int into it would take quite a lot of characters: Billion = 12 char's (long scale), in binary it fits in a uint32_t Now what about trying to encode a double ? that would be FAR FAR worse.

blocks|key|3284837|text|Thrift也是另一种类似于协议缓冲区的替代方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3284838|Java社区在序列化/反序列化和这些技术的连接大小方面有很好的基准测试：https://github.com/eishay/jvm-serializers/wiki|3284839|一般而言，JSON的线路尺寸稍大，DeSer稍差，但在普及性和无需源IDL的情况下轻松解释它的能力方面胜出。最后一点是Apache+Avro正在尝试解决的问题，它在性能方面优于两者。|3284840|微软发布了C#+NuGet包Microsoft.Hadoop.Avro。|3284841|entityMap|0|LINK|mutability|MUTABLE|url|http://incubator.apache.org/thrift/|1|https://github.com/eishay/jvm-serializers/wiki|2|https://avro.apache.org/|3|http://www.nuget.org/packages/Microsoft.Hadoop.Avro/^0|0|6|0|0|10|1A|1|0|1N|B|2|0|E|L|3|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|H|3|I|5|6|7|19|8|@]|9|@$A|1A|B|1B|1|1C]]|C|$]]|$1|J|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]|R|$5|M|N|O|C|$P|S]]|T|$5|M|N|O|C|$P|U]]|V|$5|M|N|O|C|$P|W]]]]

<a href="http://incubator.apache.org/thrift/" rel="nofollow noreferrer">Thrift</a> is another Protocol Buffers-like alternative as well.

There are good benchmarks from the Java community on serialization/deserialization and wire size of these technologies: <a href="https://github.com/eishay/jvm-serializers/wiki" rel="nofollow noreferrer">https://github.com/eishay/jvm-serializers/wiki</a> 

In general, JSON has slightly larger wire size and slightly worse DeSer, but wins in ubiquity and the ability to interpret it easily without the source IDL. The last point is something that <a href="https://avro.apache.org" rel="nofollow noreferrer">Apache Avro</a> is trying to solve, and it beats both in terms of performance. 

Microsoft has released a C# NuGet package <a href="http://www.nuget.org/packages/Microsoft.Hadoop.Avro/" rel="nofollow noreferrer">Microsoft.Hadoop.Avro</a>.

blocks|key|3284875|text|This+post比较了.NET中的序列化速度和大小，包括JSON、BSON和XML。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3284876|​|3284877|📷|atomic|3284878|3284879|3284880|3284881|3284882|http://james.newtonking.com/archive/2010/01/01/net-serialization-performance-comparison.aspx|3284883|entityMap|0|LINK|mutability|MUTABLE|url|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/85e611f0c9e643297480a0870a039d0c.png|imageAlt|2|https://ask.qcloudimg.com/http-save/yehe-900000/8f579b2a910fe9e145023d44860d943f.png|3^0|0|9|0|0|0|0|1|1|0|0|0|0|1|2|0|0|0|2K|3|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|D|3|E|5|6|7|18|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|19|8|@]|9|@$A|1A|B|1B|1|1C]]|C|$]]|$1|I|3|E|5|6|7|1D|8|@]|9|@]|C|$]]|$1|J|3|E|5|6|7|1E|8|@]|9|@]|C|$]]|$1|K|3|G|5|H|7|1F|8|@]|9|@$A|1G|B|1H|1|1I]]|C|$]]|$1|L|3|E|5|6|7|1J|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|O|3|-4|5|6|7|1O|8|@]|9|@]|C|$]]]|P|$Q|$5|R|S|T|C|$U|N]]|V|$5|W|S|X|C|$Y|Z|10|-4]]|11|$5|W|S|X|C|$Y|12|10|-4]]|13|$5|R|S|T|C|$U|N]]]]

<a href="http://james.newtonking.com/archive/2010/01/01/net-serialization-performance-comparison.aspx" rel="nofollow noreferrer">This post</a> compares serialization speeds and sizes in .NET, including JSON, BSON and XML.

<a href="https://i.stack.imgur.com/DbfMq.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/DbfMq.png" alt="alt text"></a>

<a href="https://i.stack.imgur.com/vI0HW.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/vI0HW.png" alt="alt text"></a>

<a href="http://james.newtonking.com/archive/2010/01/01/net-serialization-performance-comparison.aspx" rel="nofollow noreferrer">http://james.newtonking.com/archive/2010/01/01/net-serialization-performance-comparison.aspx</a>

blocks|key|3284896|text|下面的some+recent+benchmarks展示了流行的.NET序列化程序的性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3284897|Burning+Monks+benchmarks显示了序列化简单POCO的性能，而综合的Northwind+benchmarks显示了序列化微软的Northwind数据集的每个表中的行的组合结果。|3284898|​|3284899|📷|atomic|3284900|3284901|基本上，协议缓冲区(protobuf-net)比中最快的基类库序列化器(+DataContractSerializer)快7倍。它也比竞争对手小，因为它也比微软的最紧凑的序列化格式(JsonDataContractSerializer)小2.2x。|style|BOLD|3284902|ServiceStack的文本序列化程序最接近于二进制protobuf-net的性能，其Json+Serializer仅比protobuf-net慢2.58倍。|3284903|entityMap|0|LINK|mutability|MUTABLE|url|http://www.servicestack.net/benchmarks/|1|http://theburningmonk.com/2011/11/performance-test-json-serializers-part-ii/|2|http://www.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.100000-times.2010-08-17.html|3|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/20d5817bf8b94a76ab01590502edbad6.png|imageAlt|4|https://github.com/mgravell/protobuf-net|5|https://github.com/ServiceStack/ServiceStack.Text/^0|3|M|0|0|0|O|1|18|K|2|0|0|0|1|3|0|0|O|C|A|C|4|0|18|F|5|0^^$0|@$1|2|3|4|5|6|7|1D|8|@]|9|@$A|1E|B|1F|1|1G]]|C|$]]|$1|D|3|E|5|6|7|1H|8|@]|9|@$A|1I|B|1J|1|1K]|$A|1L|B|1M|1|1N]]|C|$]]|$1|F|3|G|5|6|7|1O|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|1P|8|@]|9|@$A|1Q|B|1R|1|1S]]|C|$]]|$1|K|3|G|5|6|7|1T|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1U|8|@$A|1V|B|1W|N|O]]|9|@$A|1X|B|1Y|1|1Z]]|C|$]]|$1|P|3|Q|5|6|7|20|8|@]|9|@$A|21|B|22|1|23]]|C|$]]|$1|R|3|-4|5|6|7|24|8|@]|9|@]|C|$]]]|S|$T|$5|U|V|W|C|$X|Y]]|Z|$5|U|V|W|C|$X|10]]|11|$5|U|V|W|C|$X|12]]|13|$5|14|V|15|C|$16|17|18|-4]]|19|$5|U|V|W|C|$X|1A]]|1B|$5|U|V|W|C|$X|1C]]]]

Here are <a href="http://www.servicestack.net/benchmarks/" rel="nofollow noreferrer">some recent benchmarks</a> showing the performance of popular .NET Serializers.

The <a href="http://theburningmonk.com/2011/11/performance-test-json-serializers-part-ii/" rel="nofollow noreferrer">Burning Monks benchmarks</a> show the performance of serializing a simple POCO whilst the comprehensive <a href="http://www.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.100000-times.2010-08-17.html" rel="nofollow noreferrer">Northwind benchmarks</a> show the combined results of serializing a row in every table of Microsoft's Northwind dataset.

<img src="https://i.stack.imgur.com/0ptir.png" alt="enter image description here">

Basically protocol buffers (<a href="https://github.com/mgravell/protobuf-net" rel="nofollow noreferrer">protobuf-net</a>) is around 7x quicker than the fastest Base class library Serializer in .NET (XML DataContractSerializer). Its also smaller than the competition as it is also 2.2x smaller than Microsofts most compact serialization format (JsonDataContractSerializer).

ServiceStack's Text serializers are the closest to matching the performance of the binary protobuf-net where its <a href="https://github.com/ServiceStack/ServiceStack.Text/" rel="nofollow noreferrer">Json Serializer</a> is only 2.58x slower than protobuf-net.

Does anyone have any information on the performance characteristics of Protocol Buffers versus BSON (binary JSON) or versus JSON in general?

<ul>
<li>Wire size</li>
<li>Serialization speed</li>
<li>Deserialization speed</li>
</ul>

These seem like good binary protocols for use over HTTP. I'm just wondering which would be better in the long run for a C# environment.

Here's some info that I was reading on <a href="http://james.newtonking.com/archive/2009/12/26/json-net-3-5-release-6-binary-json-bson-support.aspx" rel="noreferrer">BSON</a> and <a href="http://code.google.com/apis/protocolbuffers/docs/overview.html" rel="noreferrer">Protocol Buffers</a>.

Protocol Buffers versus JSON or BSON

数据结构

JSON

Java

有没有人有任何关于Protocol Buffers与BSON (二进制JSON)或JSON的性能特征的信息？Wire sizeSerialization speedDeserialization 的速度这些看起来像是通过HTTP使用的很好的二进制协议。我只是在想，从长远来看，哪个更适合C#环境。这是我在和上读到的一些信...

问协议缓冲区与JSON或BSON
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问协议缓冲区与JSON或BSONEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问协议缓冲区与JSON或BSON
EN