4

我们正在尝试创建一个应用程序，它的一部分可能是分布式的，但不一定是分布式的。为此，我们想使用现有的远程调用框架。为了不重复执行所有操作，我们希望在同一台机器上的调用中使用相同的东西，在相同的过程中。

有谁知道我们在使用这样的框架而不是直接调用 vtable 时会得到的性能/延迟损失？有比较可取的吗？

该系统应该在 Windows 和 Linux 上是可移植的

问候托拜厄斯

4

5 回答 5

3

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

于 2013-06-01T00:19:33.877 回答
1

我所知道的大多数通信框架的共同点是它们总是会序列化、发送和反序列化，这对于传递对其他线程的引用和直接访问数据（有或没有互斥体）来说总是会造成性能损失。当明智地分配职责以尽量减少沟通时，这不应该总是很戏剧化。

请注意，对于这些架构选择，性能只是要考虑的方面之一。其他是：安全性、稳定性、灵活性、部署、可维护性、许可证等......

于 2013-05-29T07:49:48.203 回答
1

从ZeroMQ / 学习基础知识：

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

这可能只是你所追求的比较。（感谢 Matthieu Rouget 的评论。）

我也想指出，虽然一些 ORB 允许您跳过编组，但您仍然无法避免动态内存分配，这对性能来说非常重要。（今天的 CPU 速度非常快，内存访问速度很慢，并且要求操作系统分配内存页面真的很慢。）

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

我们被烧毁的另一个“陷阱”是你不能定义相互递归的结构（即结构'A'包括一个'B'，它又包括一个'A'）。这意味着我们必须将它们转换为接口，它为每个结构分配一个 CORBA Servant“服务器端”（进程内），这非常占用内存。我收集了一些高级技巧来避免实际创建仆人，但最终我们只想完全摆脱 CORBA，而不是更深入地挖掘自己。

尤其是在 C++ 中，内存管理非常脆弱，难以正确编程。（参见The Rise and Fall 或 CORBA的“复杂性”部分。）我将许多人年的额外努力归功于这种技术选择。

我很想知道你是怎么相处的以及你采用了什么。

于 2014-12-02T08:49:42.817 回答
0

IBM System Object Model 创建的几个原因之一是 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）虽然直接绑定也可以是 maid（Java Proxy-> C++ 对象）。

于 2013-06-10T05:20:32.797 回答
0

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

于 2013-10-03T02:55:07.283 回答