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