使用进程间通信 (IPC) 的性能影响

Question

IPC 的用途是什么类型的，是否可以使用 IPC 在进程之间发送更大的 JSON（数百个字符）块？我是否应该尝试使用 IPC 发送尽可能小的消息，或者通过减小消息大小获得的性能提升不值得付出努力？

Answer 1

IPC 的用途是什么？是否可以在使用 IPC 的进程之间发送更大的 JSON（数百个字符）块？

IPC 的核心就是它的包装。当您需要在进程之间传递信息时使用它是一种工具，无论它是什么。该主题非常广泛，技术上包括分配共享内存和手动进行通信，但考虑到问题的语气和标签，我假设您是在谈论操作系统提供的设施。

Wikipedia 在讨论如何使用 IPC 方面做得很好，我认为我不能做得更好，所以我将专注于第二个问题。

我是否应该尝试使用 IPC 发送尽可能小的消息，或者通过减小消息大小获得的性能提升不值得付出努力？

这有点像微优化。我不能确切地说，因为我不知道微软和苹果的源代码，我真的不想深入研究 Linux 内核的 IPC 实现，但是，这里有几点：

1. IPC 是一种常见操作，因此操作系统设计人员可能会对其进行优化以提高效率。有工程师团队已经考虑过这个问题并想出了如何快速解决这个问题。
2. 跨进程/线程通信的瓶颈几乎总是同步。延迟很糟糕，但竞争条件和死锁更糟。但是，由于系统控制进程调度程序和内存管理器，因此操作系统设计人员可以通过许多创造性的方式来加快该过程。
3. 有很多方法可以使数据本身快速传输。对于操作系统，如果数据需要跨越进程边界，那么可能需要进行一些复制，但操作系统一直在到处复制内存。考虑一个命令行实用程序，例如netstat。当该可执行文件运行时，需要分配内存，需要从磁盘加载进程，并且操作系统需要进行的任何地址修复都已完成，甚至在进程启动之前。这完成得如此之快，以至于您几乎没有注意到。在 Windows 上，netstat 大约为 40k，并且几乎立即加载到内存中。 （记事本，另一个快速加载程序的大小是该大小的 10 倍，但它仍然会在很短的时间内启动。）
4. 上面#2 的最大例外是，如果您谈论的是不在同一台计算机上的进程之间的IPC。 （想想 Windows RPC）然后你真的受制于网络/通信堆栈的速度，但在这一点上，这里或那里只有几 kb 并不会产生很大的不同。 （您可以将 AJAX 视为 IPC 的一种形式，其中“进程”是服务器和您的浏览器。现在考虑 Google Docs 的运行速度。）

如果 IPC 位于同一系统上的进程之间，我认为不值得花费大量精力从消息中删除字节。让您的消息易于调试。

如果通信发生在不同机器上的进程之间，那么您可能需要考虑一些事情，因为您花了很多时间来调试问题，这些问题本来可以用更好的数据格式来调试，多出几十毫秒传输时间不值得让数据更难解析/调试。记住优化的三个规则¹：

1. 不要。
2. 不要……暂时。 （针对专家）
3. 做之前的个人资料。

---

¹ 前两条规则通常归因于迈克尔杰克逊。 （This one 不是this one）