6

我有一个在磁盘上读写文件的小程序。将其分解为最简单的级别，它从一个文件流中读取字节并将它们写入另一个文件流。它可以很好地履行职责，但这不是最快的事情。

我见过其他应用程序可以以惊人的速度通过千兆字节或更多的读/写。显然，它们的运行方式比小型 .NET 应用程序更接近金属。

用于流向/从磁盘流式传输的最有效的 .NET API 是什么？哪些 win32 API 可用（并且值得 p/调用）用于快速磁盘访问？

4

4 回答 4

12

快速文件 I/O 与您进行的特定 API 调用无关，而是关于您如何构建应用程序以使用 I/O。

例如，如果您以顺序方式在单个线程上执行所有 I/O 操作

  1. 将块读入内存
  2. 以某种方式处理内存中的块
  3. 将块写入文件
  4. 重复直到完成...

您在单线程的处理循环中限制了系统的 I/O 带宽。另一种但更复杂的设计是将应用程序多线程化以最大化吞吐量并避免等待时间。这允许系统同时利用 CPU 和 I/O 控制器带宽。一个典型的设计看起来像这样：

  1. 一个（或多个）工作线程从磁盘读取数据并将它们添加到共享输入队列
  2. 一个（或多个）工作线程从共享输入队列中读取块，处理它们并将它们添加到共享输出队列中
  3. 一个（或多个）工作线程从共享输出队列中读取处理阻塞并将它们写入适当的输出文件。

这不是一个容易正确设计的架构，需要仔细考虑以避免产生内存锁争用，或者并发 I/O 请求使系统不堪重负。您还需要提供控制元数据，以便输出处理的状态不在线程的调用堆栈上进行管理，而是在输入/输出工作队列中进行管理。您还必须确保以正确的顺序转换和写入输出，因为使用多线程 I/O，您无法确保工作以有保证的顺序放置在输入队列中。这很复杂 - 但它是可能的，并且与串行方法相比，它的吞吐量可能会有很大差异。

如果您真的有时间并且想从系统中榨取每一盎司的性能，您还可以使用I/O 完成端口（一种相对较低级别的 API）来最大化吞吐量。

祝你好运。

于 2009-07-06T15:16:27.957 回答
7

.NET 文件支持足够快（可与本机 Win32 函数相媲美）。可以帮助您提高性能的几个选项：

  1. 如果您的读/写是顺序的，请通过应用适当的策略来帮助缓存管理器 -在实例化 FileStream 时提供RandomAccess 或 SequentalScan
  2. 考虑使用更大的内存缓冲区来存储读取数据
  3. 如果复制很多小文件，可以先将多个文件一次读入内存缓冲区（见2），然后再将文件写入磁盘
  4. 如果源流和目标流位于不同的位置（即不在同一个硬盘上，可能一个文件在网络上，另一个在本地硬盘上等），您可以使用异步模式来加速，使用BeginRead读取数据，然后使用BeginWrite写入数据，在写入数据时使用 BeginRead 读取下一个数据块。
  5. 如果您仍然认为性能不够（但是根据我的测试，它与内部 Windows 副本相当甚至更快），您可以使用CopyFileEx Win32 函数（但此函数适用于文件，而不适用于流）。
于 2009-07-06T09:10:06.667 回答
0

您是否分析过您的应用程序以确定磁盘 I/O 是否是瓶颈？

你在什么类型的硬件上运行这个？硬件配置是什么？

在 .NET 中，您可以尝试System.IO.File命名空间。

对于 Win32 函数，您可以尝试 CreateFile、WriteFile、ReadFile 系列。

一个例子：

http://msdn.microsoft.com/en-us/library/bb540534(VS.85).aspx

这绝对不是切割和干燥的。这都是关于测试和测量的。

于 2009-07-05T22:16:43.360 回答
0

BinaryReader并且BinaryWriter具有合适的缓冲区大小非常快。如果您正在阅读结构，本文中描述的不安全方法将使您阅读速度更快，写作也是类似的。我也同意仔细检查 I/O 确实是瓶颈的建议。由于这样的错误，我第一次看到那篇文章。

于 2009-07-05T22:55:49.290 回答