在ZeroMQ中，"inproc +对“比"inproc”快吗？

Question

在ZeroMQ指南中，有以下内容：

如果使用inproc和套接字对，则构建一个紧密绑定的应用程序，即线程在结构上相互依赖的应用程序。当低延迟非常重要时，就这样做。

我非常关心我的应用程序的延迟。

问题：

• 是"inproc-ness“本身使其低延迟吗？
• 或者"inproc + PAIR“有什么特别之处，比inproc + "WHATEVER"更快？

Answer 1

这种不公正肯定会成为其中的一个重要部分。我推测对于inproc传输来说，与操作系统的交互是最低限度的；因此，在操作系统开销最小的情况下(消息传输可能只是memcpy的，可能还有一两个信号量，或类似的)，它是尽可能快的。

与其他传输相比，ipc、tcp等；它们都深入到操作系统的各个部分，而这些部分需要做大量的工作。例如，ipc (管道)涉及从源缓冲区复制到OS缓冲区，然后从源缓冲区复制到目标缓冲区，再加上从用户到OS执行上下文的所有转换，如果消息长度大于4kB (或系统页面大小)，则会有更多消息。有了inproc传输，转换就不存在了(信号量可能有一两个)，也可能少了一个memcpy。类似地，深入研究tcp堆栈要求有很大的可变性。

这对也有最小的复杂性和开销的分布模式。这完全是一对一的，不再是了。因此，这也是低的开销。这是我对本指南本节的解读，你已经见过了。酒吧/潜艇等都有更多的活动，比一对一通信所必需的更多。

最小的操作系统交互和复杂性相结合，以尽量减少延迟。在某些平台上，操作系统交互的最小值也将有助于保持延迟相当一致。

我对ZeroMQ的内部知识不是很了解，但是在实时操作系统之上的inproc+PAIR很有可能给出很好的延迟一致性。通常，延迟的短暂性同样重要的是延迟的一致性。