异步操作性能

Question

.NET中asynchronous programming的特性之一是在长时间运行的操作执行期间保存线程。可以将FileStream类设置为允许异步操作，从而允许运行(例如)一种复制操作，实际上不使用任何线程。令我惊讶的是，我发现运行异步流复制不仅速度较慢，而且比同步流复制使用更多的处理能力。

是否进行了任何基准测试来比较同步和异步操作执行(文件、网络等)？如果异步操作比同步操作慢几倍，那么执行异步操作而不是跨越单独的线程并在服务器环境中执行同步操作真的有意义吗？

Answer 1

实际上，文件i/o实际上是异步的条件是相当具体的，甚至在原生Win32级别也是如此。有关更多详细信息，请参阅this article。

Answer 2

引用你评论中的那篇文章来回应@Alex。

在预计I/O请求需要花费大量时间的情况下，例如刷新或备份大型数据库或缓慢的通信链路，异步I/O通常是优化处理效率的好方法。然而，对于相对较快的I/O操作，处理内核I/O请求和内核信号的开销可能使异步I/O不那么有益，特别是在需要进行许多快速I/O操作的情况下。在这种情况下，同步I/O会更好。根据使用的设备句柄类型和应用程序的特定需求，如何完成这些任务的机制和实现细节会有所不同。换句话说，通常有多种方法来解决问题。

FWIW，我认为@Alex是正确的，有另一个线程运行与你的I/O请求相关的内核代码。不过，该线程不是由您的应用程序管理的。运行内核代码的线程本身可能会在设备I/O请求上阻塞，并在向用户模式线程发出信号之前等待实际硬件完成请求，但它仍然存在。

使用异步线程不应该被认为是一种提高特定请求速度的方法，而是一种通过允许应用程序在等待相对较慢的I/O的同时继续处理其他任务来提高整体效率的方法。

Answer 3

您确定您的复制操作基准测试是正确的吗？任何异步操作都只是创建新线程并在新线程中运行操作，而让主线程来做其他事情。

与自己创建线程相比，异步操作主要提供了一些简化(更少的代码行)，但它们对性能的影响不应该比创建新线程更大。