在ZeroMQ中，“ inproc + PAIR”是否比“ inproc”更快？

Question

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

  

如果使用 inproc 和套接字对，则您正在构建一个紧密绑定的应用程序，即线程在结构上相互依赖的应用程序。当低延迟确实至关重要时，请执行此操作。

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

问题：

• 是否仅因为“ inproc -ness使其低延迟？

• 或者“ inproc + PAIR ”有什么特别之处，它比 inproc + "WHATEVER" 快吗？

Answer 1

_{如果一个人从未使用过ZeroMQ，
在深入了解更多细节之前，请先阅读“ ZeroMQ Principles in less than Five Seconds”}

  

Q ：是否仅凭其“ inproc -ness”使其低延迟？

是，_{。 。 。正如bazza昨天已经说的一般，让我加几分钱：}

1） inproc:// - transport-class 是无堆栈，无协议且纯净的（因此速度快且几乎零延迟）RAM内存区域映射工具
和
也 _{（如第二个问题所述）}

  

Q ：或者“ inproc + PAIR ”有什么特别之处，它比 inproc + "WHATEVER" 快>？

2） PAIR/PAIR -可伸缩形式通信模式原型 无需多说，Pattern与原型相关的，多方的行为握手（与其他一些分布式的有限状态自动机相比（表示 Pattern的 原型行为状态和所有分布式对等方之间的过渡-不带有PAIR/PAIR专有的一对一数字发射软管），因此这里没有任何内容，除了线程安全的本地指针机制两侧，加上一些Context()实例信号-顺便说一句，您可能已经注意到，对于纯 inproc:// -运输类应用程序，您可以实例化具有零I / O线程的Context( 0 )，因为在这种情况下，Context()信号根本不需要它们，因为它只管理本地RAM存储器上的指针提示区域-好可爱，不是吗？）

Answer 2

毫无节制无疑将成为其中的很大一部分。我推测对于inproc传输，与操作系统的交互几乎是最少的。因此，在操作系统开销最小的情况下（消息传输可能仅比memcpy少，并且可能只有一两个信号灯，或类似的信号量），它的速度要尽可能快。

与其他传输方式（ipc，tcp等）相比；它们都深入到需要大量工作的操作系统中。例如，ipc（管道）涉及从源缓冲区复制到OS缓冲区，然后从该缓冲区复制回目的地缓冲区，以及从用户到OS执行上下文的所有转换，如果消息是> 4kB长（或任何系统页面大小）。使用inproc传输时，转换就不存在了（信号量可能是一两个），也可能少了一个转换。同样，深入研究tcp堆栈也要求很多可变性。

PAIR对分发模式的复杂性和开销也最小。严格来说是一对一，仅此而已。因此，其开销也很低。这就是我对this section in The Guide的阅读，您已经发现过。 PUB / SUB等的所有功能都在进行中，比一二一通信所需的更多。

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

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