代码之家 › 专栏 › 技术社区 › LicenseQ

异步操作性能

filestream asynchronous .net

0

LicenseQ · 技术社区 · 17 年前

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

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

3 回复 | 直到 15 年前

1

Nick Gunn 17 年前

实际上,文件I/O的条件 事实上 即使在本机win32级别,异步也是相当特定的。见 this article 了解更多详细信息。

2

tvanfosson 17 年前

引用你在评论中所写的文章对@alex的回复。

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

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

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

3

1

Alex Reitbort 17 年前

您确定您的复制操作正确地进行了基准测试吗?任何异步操作都只是创建新线程并在新线程中运行该操作,同时让主线程做其他事情。

异步操作通常会对自己创建线程进行一些简化(减少代码行),但它们不应比创建新线程更影响性能。