在 ZeroMQ 的指南中，有这样的：
如果您使用
inproc和套接字对，则您正在构建一个紧密绑定的应用程序，即您的线程在结构上相互依赖的应用程序。当低延迟非常重要时，请执行此操作。
我非常关心我的应用程序的延迟。
问题：
仅是“inproc-ness”使其延迟低吗？
或者说“inproc + PAIR”比inproc + "WHATEVER"快吗？
【问题讨论】：
标签： performance zeromq pyzmq low-latency
如果有人从未使用过 ZeroMQ，
在这里可以先看看“ZeroMQ Principles in less than Five Seconds”
在深入了解更多细节之前
Q：仅仅是“
inproc-ness”的延迟低吗？
是的， 。 . .正如bazza 昨天已经概括了，让我加几分钱：
1) inproc://-transport-class 是一种无堆栈、无协议且纯（因此快速且几乎零延迟）RAM 内存区域映射工具
和
也（如第二个问题中所问）
Q：或者说“
inproc + PAIR”比inproc + "WHATEVER"更快有什么特别之处吗？ em>
2) PAIR/PAIR-Scalable-Formal-Communication-Pattern archetype 没有添加任何额外内容，模式的原型相关，多（多）方行为握手（与其他一些分布式有限状态自动机相比（表达模式的 原型行为所有分布式对等点之间的状态和转换 - 不使用 PAIR/PAIR 独家 1 对 1 数字消防软管）所以这里没有添加任何内容，除了两侧的线程安全本地指针机制外加一些Context()-instance 信号 - 顺便说一句。您可能已经注意到，对于纯-inproc://-transport-class 应用程序，您可以实例化 Context( 0 )拥有零 I/O 线程，因为在这些情况下，Context()-signaling 根本不需要它们，因为它只是管理本地 RAM 内存区域上的指针技巧——太可爱了，不是吗？ )
【讨论】：
inproc-ness 肯定会成为其中的重要组成部分。我推测对于 inproc 传输，与操作系统的交互最少；因此，以最小的操作系统开销（消息传输可能比 memcpy 的多一点，也可能是一两个信号量，或类似的）它尽可能快。
与其他传输方式、ipc、tcp 等相比；他们都深入到需要大量工作的操作系统中。例如，ipc（管道）涉及从源缓冲区复制到 OS 缓冲区，然后从该缓冲区复制回目标缓冲区，以及从用户到 OS 执行上下文的所有转换，如果消息是> 4kB 长（或任何系统页面大小）。使用 inproc 传输时，不存在转换（对于信号量来说可能是一两个），并且可能少了一个 memcpy。同样，深入研究 tcp 堆栈也需要很多可变性。
PAIR 也具有最小的复杂性和分配模式的开销。严格来说是一对一的，不再赘述。所以开销也很低。这是我对this section in The Guide 的阅读，您已经遇到过。 PUB/SUB 等都进行了更多操作，超出了一对一通信所必需的范围。
最低限度的操作系统交互和复杂性相结合，可最大限度地减少延迟。在某些平台上，最少的操作系统交互也有助于保持延迟相当一致。
我对 ZeroMQ 的内部知识并不深入，但很有可能在实时操作系统之上的 inproc+PAIR 可以提供非常好的延迟一致性。通常，延迟的一致性与延迟的缩短一样重要。
【讨论】：