在什么时候异步读取磁盘I / O比同步更有效？

22

假设有一些代码可以读取多个使用者的文件，并且文件的大小是任意的：异步读取文件的效率如何提高？或者换一种说法，要同步读取文件，文件必须快到多小？

我注意到（也许我不正确），当读取非常小的文件时，异步读取它们比同步读取（尤其是.NET）需要更长的时间。我假设这与设置时间有关，例如I / O完成端口，线程等。

有什么经验法则可以帮助您吗？还是取决于系统和环境？

efficiency async io

— 淡淡的
source

您可以提供用于基准测试的代码吗？我认为只有在文件大小小于流读取器的内部缓冲区大小的情况下，才可能发生这种情况。但是，如果您必须阅读那么多小文件，则可能会遇到磁盘I / O的其他问题

— Daniel Iankov 2012年

恐怕我没有方便的代码。从那以后我就一直在想这件事。代码在.NET中，本质上是for循环中的直接File.ReadAllBytes（）与FileStream.BeginRead（）

— 令人毛骨悚然的2012年

当代表效率的曲线交叉时，异步IO会以高于同步IO曲线的值退出交叉。

— Thomas Eding 2012年

14

不幸的是，答案是“取决于情况”。您可以编写一个小程序凭经验确定异步读取和同步读取的时间，这很容易。

这将取决于许多因素。它们是否存储在旋转磁盘，SSD或网络驱动器上？您使用哪种CPU？多少个插座/芯？您是在VM还是裸机上运行？您正在运行古老的操作系统还是现代的操作系统？

— 马丁·马丁
source

1

是的，我想了很多。我想我希望可以进行某种研究作为指导或经验法则。

— blesh 2012年

9

异步具有3个主要优点：

我相信异步读取的主要优点是当您处理大量文件或需要大量CPU能力时。

— 欣快的
source

对于第2点，请注意，如果I / O操作是瓶颈，它将不会优化任何内容。如果通过RAID或网络并行访问位于不同磁盘上的文件，情况将有所不同。

— Arseni Mourzenko 2012年

5

嗯，我在理解＃1的含义时遇到了麻烦。我会说这是实践中的另一种方式。因为在异步情况下，您现在将线程从blocked waiting for I/O（0％CPU）更改为continue normal processing（> 0％CPU）。

— Isak Savo 2012年

3

这取决于

要记住的一件事是在流程之间进行上下文切换的代价是多么昂贵。Node.JS是按其原样设计的，因为它假设进行上下文切换非常昂贵，否则您将在IE上等待大量进程，这将使计算机瘫痪。

另一方面，Erlang使流程上下文切换非常便宜，因此所有内容都可以同步，并且Erlang运行时可以跟踪整个过程。

因此要考虑的因素：

而且我确定我会省去六个因素

— 扎卡里K
source

2

我不确定是否有特定的“要点”，但是当您有很多线程在工作时，这才是最有意义的，因为它使您可以将I / O与其他工作重叠。如果您有空闲的空闲线程，那么异步读取不会给您带来任何好处。只有当工作队列填满并且线程可以有效地执行其他工作而不是等待I / O时，异步文件访问才可以发挥任何优势。

— TMN
source

是的，这就是多线程的重点！

— 弗拉德（Vlad）2012年

1

我认为这里的问题不是读取速度，而是延迟。

如果您是从网络驱动器读取数据，或者从队列较长的慢速机械硬盘驱动器读取数据，那么读取性能将大打折扣。而且，如果您的应用程序也在GUI线程中进行读取，那么在这种情况下，这是一个非常糟糕的应用程序，那么这对于用户来说将是很糟糕的。

— 编码器
source