诸如Corba(如TAO)、Thrift、D-Bus、ICE等框架的进程内调用性能

omniORB很长一段时间以来都有一个可进行直接调用的同址快捷方式，但从版本4开始，它有一个专有的POA策略，该策略绕过了更多所需的CORBA行为，使其几乎与直接虚拟调用一样快。请参阅omniORB Wiki并搜索"快捷本地呼叫"。不幸的是，这似乎没有在官方文档中，至少我能找到。

我所知道的大多数通信框架的共同之处在于，它们总是序列化、发送和反序列化，这总是会影响到将引用传递给其他线程和直接访问数据(使用或不使用互斥锁)的性能。如果能明智地分配职责，尽量减少沟通，这种情况就不应该总是很严重。

注意，对于这些类型的体系结构选择，性能只是需要考虑的方面之一。其他包括:安全性、稳定性、灵活性、可部署性、可维护性、许可证等等。

From ZeroMQ/Learn basics:

2011年，CERN(欧洲核研究组织)比较了CORBA、Ice、Thrift、ZeroMQ、YAMI4、RTI和Qpid (AMQP)。阅读他们的分析和结论。(PDF)

这可能就是你想要的比较。(感谢Matthieu Rouget的评论)

我还想指出，虽然一些orb允许您跳过编组，但您仍然无法避免动态内存分配，这才是真正影响性能的因素。(今天的cpu非常快，内存访问很慢，要求操作系统分配内存页真的慢。)

因此，在c++中，您可能只返回const string &，而CORBA的c++绑定将强制您动态分配和释放字符串或数据结构(无论是通过返回类型还是输出参数)。如果方法跨进程/网络调用，这一点并不重要，但在进程内，与普通c++相比，这一点就变得相当重要了。

另一个让我们感到困惑的问题是，你不能定义相互隐归的结构(即结构'A'包含'B'，而'B'又包含'A')。这意味着我们必须将它们转换为接口，这将为每个结构分配一个CORBA server"服务器端"(进程内)，这将占用大量内存。我认为有一些高级技巧可以避免实际上创建仆从，但最终我们只想完全摆脱CORBA，而不是让自己陷得更深。

特别是在c++中，内存管理非常脆弱，很难正确编程。(参见CORBA的兴衰，"复杂性"一节。)我把许多人年的额外工作归功于这项技术的选择。

我很想知道你在& &;

创建IBM系统对象模型的几个原因之一是CORBA。IBM SOM是"本地CORBA"，IBM DSOM是CORBA的实现。

你应该估计一下somFree.

另一个选项是UNO(来自OpenOffice.org)。我不能说我喜欢UNO，它更糟糕，但它比被遗忘已久的SOM更成熟。UNO本地(进程内)生态系统根据编程语言划分为多个分区。c++和Java是最常见的分区。没有序列化，但是分区间交互的首选机制是后期绑定(Java Proxy->Java Dispatch-> c++ Dispatch-> c++ object)(有点像OLE中的IDispatch)，尽管直接绑定也可以是女仆(Java Proxy-> c++ object)。

当避免数据编组时，ICE from ZeroC明确支持并置调用。您可以在他们的网站上找到详细的文档:http://doc.zeroc.com/display/Ice/Location+Transparency虽然搭配调用与虚拟方法调用有一些开销，不幸的是我没有实际的数字，但它也取决于条件，即在特定适配器中注册了多少仆人等。