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