我正在编写一些代码，涉及比较开源项目thrift-protobuf-compare中的protobuf和thrift。目前它涵盖了一些序列化方面，但我打算涵盖更多内容。我的博客上讨论了Thrift和Protobuf的结果，我会在以后添加更多内容。 你可以查看代码来比较API、描述语言和生成的代码。我很乐意接受贡献，以实现更全面的比较。
我“待办事项”清单上的首要任务之一是将谷歌内部的Protocol Buffer性能基准移植过来——这主要涉及将机密消息格式转换为完全平淡无奇的格式，然后对数据执行相同操作。
完成此操作后，我想你可以在Thrift中构建相同的消息，然后比较性能。
换句话说，我现在还没有相关的数据，但希望在接下来的几周内能够提供给您...
为了支持Vladimir关于IIOP的观点，这里有一个有趣的性能测试，可以提供一些额外的信息，因为它比较了Thrift和CORBA。(Performance_TIDorb_vs_Thrift_morfeo.pdf // 链接不再有效) 引用研究中的话：
- Thrift在处理小数据（基本类型作为操作参数）方面非常高效。
- 与CORBA相比，Thrift的传输在处理中大型数据（struct和复杂类型> 1千字节）时不太高效。
另一个奇怪的限制，与性能无关，是Thrift仅限于将几个值作为结构返回 - 尽管这个问题像性能问题一样可以得到改善。
有趣的是，Thrift IDL 与 CORBA IDL 非常相似，这很好。我没有使用过 Thrift，它看起来很有趣，特别是对于较小的消息，而且一个设计目标是更少的繁琐安装，这些都是 Thrift 的其他优点。尽管如此，CORBA 拥有不好的声誉，但是像 omniORB 这样的许多优秀实现已经存在，并且具有易于安装和使用的 Python 绑定。 编辑：Thrift 和 CORBA 的链接已不再有效，但我找到了 CERN 的另一篇有用论文。他们评估了替换他们的 CORBA 系统的方案，虽然他们评估了 Thrift，但最终他们选择了 ZeroMQ。虽然在性能测试中 Thrift 表现最佳，达到了每秒 9000 条消息，而 ZeroMQ 是 8000 条，而基于 CORBA 的 RDA 是 7000 多条，但由于其他问题，特别是：他们选择不进一步测试 Thrift。它仍然是一个带有错误实现的不成熟产品
服务器端：https://github.com/vlachenal/webservices-bench
客户端：https://github.com/vlachenal/webservices-bench-client
它还没有完成，已经在我的个人电脑上运行（我必须请求服务器来完成测试）......但结果可以在以下链接中查看：
结论如下：
节俭（Thrift）提供了最佳性能并易于使用；带有JSON内容类型的RESTful Web服务接近于Thrift的性能，可以“即刻在浏览器中使用”，而且相当优雅（在我看来）；SOAP性能非常差，但提供了最佳数据控制；协议缓冲区（Protocol Buffers）具有良好的性能......直到3个同时调用...我不知道为什么。它很难使用：我放弃了（暂时）使用MapStruct让它工作，也不尝试使用Dozer。项目可以通过拉取请求（无论是修复还是其他结果）完成。
