IPC的目的是什么类型的使用,是否可以在使用IPC的进程之间发送更大的JSON(数百个字符)块？我是否应该尝试尽可能使用IPC发送尽可能小的消息,或者减少消息大小所带来的性能提升是否值得付出努力？
解决方法:
What type of usage is IPC intended for and is it is OK to send larger chunks of JSON (hundreds of characters) between processes using IPC?
在它的核心,IPC就是它所说的.当您需要在进程之间传递信息时,它是一种工具,无论可能是什么.主题非常广泛,技术上包括分配共享内存和手动进行通信,但考虑到问题的基调和标签,我假设您正在谈论操作系统提供的设施.
Wikipedia很好地讨论了如何使用IPC,我认为我不能做得更好,所以我将专注于第二个问题.
Should I be trying to send as tiny as message as possible using IPC or would the performance gains coming from reducing message size not be worth the effort?
这有点像微优化.我不能肯定地说,因为我不了解微软和Apple的源代码,我真的不想深入研究Linux内核的IPC实现,但是,这里有几点：
> IPC是一种常见操作,因此OS设计人员可能会对其进行优化以提高效率.有一些工程师团队已经考虑了这个问题,并想出了如何快速实现这一目标.
>跨进程/线程的通信瓶颈几乎总是同步.延迟很糟糕,但竞争条件和僵局更糟糕.然而,由于系统控制进程调度程序和内存管理器,因此OS设计人员可以通过许多创造性的方法来加速该过程.
>有很多方法可以快速实现数据传输.对于操作系统,如果数据需要跨越进程边界,则可能需要进行一些复制,但操作系统会一直复制内存.想想命令行实用程序,比如netstat.当运行该可执行文件时,需要分配内存,需要从磁盘加载进程,并且在进程甚至可以启动之前完成修复操作系统需要执行的任何地址.这样做很快,你几乎都注意不到.在Windows上,netstat大约是40k,它几乎立即加载到内存中. (记事本,另一个快速加载器的大小是它的10倍,但它仍然会在很短的时间内启动.)
>上面#2的一个大例外是你在谈论不在同一台计算机上的进程之间的IPC. (想想Windows RPC)然后你真的受到网络/通信堆栈速度的束缚,但是在这一点上,这里或那里几kb不会产生很大的不同. (您可以将AJAX视为IPC的一种形式,其中“流程”是服务器和浏览器.现在考虑Google Docs的运行速度.)
如果IPC位于同一系统上的进程之间,我认为从您的消息中削减字节值得花费大量精力.使您的消息易于调试.
如果在不同机器上的进程之间进行通信,那么您可能需要考虑一些事情,花了很多时间来调试问题,这些问题本来就很简单,数据格式更好,几十毫秒的传输时间也没有.不值得使数据更难解析/调试.记住优化的三个规则1：
>不要.
>不要…… (专家)
>在你做之前的配置文件.
