blocks|key|1688142|text|在thrift-protobuf-compare项目维基上可以找到最新的比较。它还包括许多其他的序列化库。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1688143|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/eishay/jvm-serializers/wiki/^0|1|N|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Latest comparison available here at the <a href="https://github.com/eishay/jvm-serializers/wiki/" rel="noreferrer">thrift-protobuf-compare</a> project wiki. It includes many other serialization libraries.

blocks|key|1472849|text|我正在用open+source+project+named+thrift-protobuf-compare编写一些代码，比较protobuf和thrift。目前，它只涵盖了几个序列化方面，但我打算介绍更多。结果(针对Thrift和Protobuf)在我的博客中进行了讨论，当我到达它的时候，我会添加更多。您可以查看代码来比较API、描述语言和生成的代码。我将很高兴有贡献，以实现更全面的比较。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1472850|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/thrift-protobuf-compare/|1|http://eishay.blogspot.com/search/label/Thrift|2|http://eishay.blogspot.com/search/label/protobuf^0|4|1D|0|30|6|1|37|8|2|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]|$A|T|B|U|1|V]|$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]|N|$5|G|H|I|C|$J|O]]]]

I'm in the process of writing some code in an <a href="http://code.google.com/p/thrift-protobuf-compare/" rel="noreferrer">open source project named thrift-protobuf-compare</a> comparing between protobuf and thrift. For now it covers few serialization aspects, but I intend to cover more. The results (for <a href="http://eishay.blogspot.com/search/label/Thrift" rel="noreferrer">Thrift</a> and <a href="http://eishay.blogspot.com/search/label/protobuf" rel="noreferrer">Protobuf</a>) are discussed in my blog, I'll add more when I'll get to it.
You may look at the code to compare API, description language and generated code. I'll be happy to have contributions to achieve a more rounded comparison.

blocks|key|1687904|text|你可能会对这个问题感兴趣："Biggest+differences+of+Thrift+vs+Protocol+Buffers?"|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1687905|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/69316/biggest-differences-of-thrift-vs-protocol-buffers^0|D|1G|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You may be interested in this question: <a href="https://stackoverflow.com/questions/69316/biggest-differences-of-thrift-vs-protocol-buffers">"Biggest differences of Thrift vs Protocol Buffers?"</a>

blocks|key|1472965|text|我用许多其他数据格式(xml，json，默认对象序列化，hessian，一种专有的)和库(jaxb，fast+infoset，手写的)测试了PB的性能，用于数据绑定任务(读写)，但没有包括thrift的格式。具有多个转换器(如xml)的格式的性能有很大的差异，从非常慢到非常快。作者的声明与感知到的表现之间的相关性相当弱。尤其是对于做出最疯狂声明的软件包来说。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1472966|不管它有什么价值，我发现PB的性能被过分炒作了(通常不是它的作者，而是其他只知道谁写了它的人)。在默认设置下，它不能击败最快的文本xml替代方案。使用优化模式(为什么这不是默认模式？)，它的速度要快一些，可与最快的JSON包相媲美。Hessian相当快，文本json也是如此。专业的二进制格式(这里没有名字，它是公司内部的)是最慢的。对于较大的消息，Java对象序列化速度较快，而对于较小的对象(即高度固定的每操作noverhead)，Java对象序列化速度较慢。使用PB消息大小是紧凑的，但是考虑到您必须做的所有权衡(数据不是自描述的:如果您丢失模式，您就会丢失数据；当然还有索引和值类型，但是如果您愿意，可以从您拥有的反向工程返回到字段名称)，我个人只会在特定的用例中选择它--对大小敏感的、紧密耦合的系统，在这种系统中，接口/格式从不(或者很少)更改。|1472967|我的观点是：(a)实现通常比(数据格式)规范更重要，(b)端到端，最佳(不同格式)之间的差异通常不足以决定选择。也就是说，你最好选择你最喜欢使用的格式%2BAPI/lib/framework(或者有最好的工具支持)，找到最好的实现，看看它是否足够快。如果(且仅当！)不，考虑下一个最好的替代方案。|1472968|ps。不确定这里的EJB3是什么。也许只是简单的Java序列化？|1472969|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I did test performance of PB with number of other data formats (xml, json, default object serialization, hessian, one proprietary one) and libraries (jaxb, fast infoset, hand-written) for data binding task (both reading and writing), but thrift's format(s) was not included. Performance for formats with multiple converters (like xml) had very high variance, from very slow to pretty-darn-fast. Correlation between claims of authors and perceived performance was rather weak. Especially so for packages that made wildest claims.

For what it is worth, I found PB performance to be bit over hyped (usually not by its authors, but others who only know who wrote it). With default settings it did not beat fastest textual xml alternative. With optimized mode (why is this not default?), it was bit faster, comparable with the fastest JSON package. Hessian was rather fast, textual json also. Properietary binary format (no name here, it was company internal) was the slowest. Java object serialization was fast for larger messages, less so for small objects (i.e. high fixed per-operation noverhead).
With PB message size was compact, but given all trade-offs you have to do (data is not self-descriptive: if you lose the schema, you lose data; there are indexes of course, and value types, but from what you have reverse-engineer back to field names if you want), I personally would only choose it for specific use cases -- size-sensitive, closely coupled system where interface/format never (or very very rarely) changes.

My opinion in this is that (a) implementation often matters more than specification (of data format), (b) end-to-end, differences between best-of-breed (for different formats) are usually not big enough to dictate the choice.
That is, you may be better off choosing format+API/lib/framework you like using most (or has best tool support), find best implementation, and see if that works fast enough.
If (and only if!) not, consider next best alternative.

ps. Not sure what EJB3 here would be. Maybe just plain of Java serialization?

blocks|key|1472796|text|在我的PBs“待办事项”列表中，最重要的一件事就是移植谷歌内部的Protocol+Buffer性能基准--它主要是将机密消息格式转换为完全平淡的格式，然后对数据执行同样的操作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1472797|当这一切完成后，我想你可以在Thrift中构建相同的消息，然后比较性能。|1472798|换句话说，我还没有给你提供数据--但希望在接下来的几周里……|1472799|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

One of the things near the top of my "to-do" list for PBs is to port Google's internal Protocol Buffer performance benchmark - it's mostly a case of taking confidential message formats and turning them into entirely bland ones, and then doing the same for the data.

When that's been done, I'd imagine you could build the same messages in Thrift and then compare the performance.

In other words, I don't have the data for you yet - but hopefully in the next couple of weeks...

We're looking into transport/protocol solutions and were about to do various performance tests, so I thought I'd check with the community if they've already done this:
Has anyone done server performance tests for simple echo services as well as serialization/deserialization for various messages sizes comparing EJB3, Thrift, and Protocol Buffers on Linux?
Primarily languages will be Java, C/C++, Python, and PHP.
Update: I'm still very interested in this, if anyone has done any further benchmarks please let me know. Also, very interesting benchmark showing compressed JSON performing similar / better than Thrift / Protocol Buffers, so I'm throwing JSON into this question as well.

Performance comparison of Thrift, Protocol Buffers, JSON, EJB, other?

性能测试

服务器

Python

Linux

JSON

Java

我们正在研究传输/协议解决方案，并即将进行各种性能测试，所以我想我应该向社区确认一下他们是否已经这样做了：有没有人做过简单回显服务的服务器性能测试，以及各种消息大小的序列化/反序列化测试，比较了EJB3、Thrift和Protocol Buffers在Linux上的性能？主要的语言是Java、C/C++、Python和PHP。更新:我仍然对此非常感兴趣，如果有人做了进一步的基准测试，请让我知道。此

问Thrift，Protocol Buffers，JSON，EJB，other？
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Thrift，Protocol Buffers，JSON，EJB，other？EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Thrift，Protocol Buffers，JSON，EJB，other？
EN