我有一段 C# 5.0 代码可以生成大量的网络和磁盘 I/O。我需要并行运行此代码的多个副本。以下哪项技术可能会给我带来最佳性能：
带有等待的异步方法
直接使用TPL中的Task
TPL 数据流核心
反应式扩展
我不太擅长这种并行的东西，但如果使用较低的杠杆，比如 Thread，可以给我带来更好的性能，我也会考虑这样做。
【问题讨论】：
nuget的上下文，为什么它只与TPL-Dataflow一起使用？您使用的是 .NET 4.0 Async CTP 还是 .NET 4.5？
标签： task-parallel-library system.reactive async-await conceptual tpl-dataflow
这就像通过询问最快的方法来解开安全带来尝试优化跨大西洋航班的长度。
让我们给出一个有用的答案。将性能视为活动的“类” - 每一个都慢一个数量级（至少！）：
如果您进行甚至一个活动 #3，则对活动 #1 和 #2 进行典型的优化（例如优化线程库）毫无意义 - 它们完全被磁盘命中所掩盖。 CPU 技巧也是如此 - 如果您经常发生 L2/L3 缓存未命中，那么通过手写汇编节省几个 CPU 周期是不值得的（这就是为什么像 loop unrolling 这样的事情现在通常是个坏主意）。
那么，我们可以从中得到什么？有两种方法可以让你的程序更快，要么从 #3 提升到 #2（这通常是不可能的，这取决于你在做什么），或者减少 I/O .在大多数现代应用程序中，I/O 和网络速度是速率限制因素，而这是您应该尝试优化的。
【讨论】：
面对“大量的网络和磁盘 I/O”，这些选项之间的任何性能差异都无关紧要。
一个更好的问题是“哪个选项最容易学习和开发？”或者“从现在起五年内维护此代码的最佳选择是什么？”为此，我建议首先使用 async，或者如果您的逻辑更好地表示为流，则建议使用 Dataflow 或 Rx。
【讨论】：
这是一个较老的问题，但对于阅读此内容的任何人......
这取决于。如果您尝试使用 50B 消息使 1Gbps 链路饱和，即使通过原始套接字进行简单的非阻塞发送，您也会受到 CPU 的限制。另一方面，如果您对 1Mbps 的吞吐量感到满意，或者您的消息大于 10KB，那么这些框架中的任何一个都可以胜任。
对于低带宽的情况，我建议按易用性进行优先级排序，即按此顺序排列 async/await、Dataflow、Rx、TPL。请注意，高带宽应用程序应该像低带宽应用程序一样进行原型设计，然后再进行优化。
对于真正的高带宽应用，我可以推荐 Dataflow over Rx，因为 Rx 不是为高并发设计的。原始 TPL 是底层，如果您可以处理复杂性，它可以保证最低的开销。如果您可以有效地使用专用线程，那将更快。 Async/await 与 Dataflow IMO 没有任何性能差异。开销似乎相当，所以选择一个更合适的。
【讨论】：