dobbs博士的一篇文章,其中有一个例子with named pipes：
与同一台机器中的其他IPC方法相比,性能损失是多少？当扩大进程数量或传输的数据量时,首先遇到的问题是什么？
例如.如果我们使用文件代替管道,我们会遇到锁定问题和磁盘速度.
请注意,通过必须序列化正在传输的数据结构,已经存在开销,这是我失去效率的基准.
PS.对管道的兴趣是因为它们易于在每个进程中实现(Console.Readline,Console.WriteLine),很容易为它们编写MSMQ和异步HTTP接口,以及对Unix和命令行的热爱.
匿名管道基于共享内存,但不支持异步操作(通过ReadFileEx,ReadFileWrite).因此,性能问题(缺点)是1)同步操作,2)存储器复制,3)进程间同步.通常,“原始”共享内存(没有实际后备文件的内存映射文件)和命名管道将更快,并且套接字和窗口消息将更慢(比匿名管道).
您不能将I / O完成端口(IOCP)与匿名管道一起使用,而是必须“轮询”管道,从而产生额外的上下文切换.除了序列化数据之外,序列化数据必须在内存中复制,因为您无法直接写入共享内存.一个进程还必须等待另一个进程,这意味着另一个进程必须发出进程间同步原语的信号.性能在很大程度上取决于消息的大小(读/写调用与发送数据量的比率),因为对于每次读/写,进程必须进行上下文切换并可能进行旋转/休眠.
除“原始”共享内存之外的所有方法都需要内存复制和某种进程间信令(同步),因此匿名管道的主要缺点是同步操作.当cpu花费大部分时间进行上下文切换时,你会在传输大量消息时达到上限.
性能方面,命名管道更好,因为您可以使用IOCP处理工作线程处理异步通知,甚至可以通过一次调用接收多个消息,从而减少API开销.如果制作自己的组件,给管道命名的额外麻烦是值得的(甚至可以跨网络连接).后来的Windows版本为本地套接字实现了特殊的路由,这也支持IOCP.
最快的方法是直接使用共享内存,但是您必须自己处理进程间同步.可以自己实现无锁管道,但是如果你不经常传输数据,你仍然必须使用同步原语来通知/唤醒监听过程.
另请注意,使用文件并不意味着您会受到磁盘速度的限制,因为您可以使用内存映射文件,即使使用普通文件,缓存管理器也会处理读/写.其他方法(RPC,剪贴板等)基于这些“标准”方法,这意味着它们只需添加一些额外的协议层,并且更容易/更有用,或者更适合某些编程环境(但是不要更快).
