应用程序间的通信

只要在一台机器上运行，进程间通信从根本上受到总线带宽的限制。 内存到内存的拷贝，无论是在TCP / IP堆栈，命名管道支持代码还是共享内存中完成。 这使得他们都同样高效。

一个细节很重要，传输的数据量以及完成工作所需的软件层数。 内存总线带宽仅在数据量较大时才会节制。 远程过程调用协议（如COM）不一定是这种情况。 只有函数调用的参数需要被序列化，如果你不传递数组，那么可能只有少数几个字节。 现在开销很重要，当使用像COM这样的高级协议时，会有相当多的开销。

使用套接字的明显缺点是你必须自己编写所有的de / serialization代码。 如果协议与组件不平凡是不平凡的。 为了方便而交换你的工作时间是典型的选择，只有你可以做到。

那么，想一想 – 套接字是最低级别，COM是使用套接字，ActiveX是使用COM。 那么哪一个更快？ 当然，插座。 但是，只有当您询问程序执行速度和数据传输速率时。 但是，如果你不知道自己在做什么，使用套接字来开发程序会困难得多。 更何况，你可能会想出一些糟糕的实现，比COM更糟糕。 而且，当你使用ActiveX时，没有太多的可重复使用的组件可以获得，更不用说如果你想与MS Office通信，你将不得不使用COM。

嗨，你可以使用共享内存？ 即使Oracle在其产品中使用共享内存。 共享内存很快。

对于你想要做什么或者你需要做什么考虑，你不会给出太多的细节。 例如，“快”你的意思是高带宽？ 低延迟？ 以后有可能需要通过计算机进行通信吗？ 等等。

也就是说，ActiveX是COM的一个特例（ 介绍activeX ）。 如果你已经熟悉了COM或者ActiveX，并且根据你正在尝试做什么，你可能就能够写出相对较少的代码，因为MS开发工具可以为你处理大量的代码。

如果你不熟悉它，这是一个相当复杂的技术，可能是棘手的。 所以如果你只是想实现一些基本的进程间通信，使用套接字可能会更容易。 另一方面，这可能需要更多的低层次的工作。

我也将IPC委托给一个框架，例如ACE（自适应通信框架）。 例如，Ace的实现是稳定的，它是跨平台的。

实际上哪个更快可能并不重要。 如果是这样，那么选择最方便开发和维护的方法。 即使不能保存任何可测量的运行时间，也可以节省自己的时间。

ActiveX在COM上或多或少是一个奇特的营销名称（一个ActiveX组件/控件是一个只支持IUnknown接口的对象），所以你的选择是真正的COM和Socket。

对于跨进程的通信，你可以用套接字写更快的东西…如果你是一个好的套接字和Windows程序员，因为你将自己做，因为套接字基本上不会帮你。 这并不意味着COM不是很快，或者性能不好，但是从理论上讲，总是可以做得比一个开箱即用的系统更好，但是只有掌握了所有的东西。

最后一件事，如果你需要与第三方产品或除Windows以外的其他平台进行通信，套接字更便携。

很难说哪个更快，但使用COM肯定是你列出的选择中最灵活的选择。 除非你喜欢通过字节流徘徊。