5

您可以通过多线程使文件复制更快吗？

编辑：为了澄清，假设您正在实施 CopyFile(src, tgt)。在某些情况下，您可以使用多个线程使其运行得更快，这似乎是合乎逻辑的。

编辑更多想法：

自然，这取决于所讨论的硬件/存储。

例如，如果您要从一个磁盘复制到另一个磁盘，很明显您可以使用两个线程同时读/写，从而节省了两个线程中最快的（通常是读取）的性能成本。但是您实际上并不需要多个线程来并行读取/写入，只需要异步 IO。

但是，如果 async-IO 在从不同磁盘读取/写入时真的可以加快速度（最高 2 倍），为什么这不是 CopyFile 的默认实现？（或者是吗？）

4

6 回答 6

4

如果你不小心，你可以让它变慢。磁盘擅长序列化访问，如果您有多个线程，磁盘头将无处不在。现在，如果您正在处理高性能 SAN，那么您的性能可能会有所提高，并且 SAN 将处理优化磁盘访问。

于 2009-02-11T18:49:01.803 回答
3

这是一篇关于 Vista SP1 中文件复制性能改进的博客文章：

http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx

进行高性能文件复制很疯狂，您必须考虑缓存行为和网络驱动程序限制等因素。

所以总是使用 OS 文件复制功能（在 Windows 下是 FileCopyEx），不要自己写。

于 2009-02-11T19:32:13.087 回答
2

我认为不会。CPU 能做的事情太少了。

于 2009-02-11T18:50:01.597 回答
2

如果文件位于不同的设备上，您会看到一个好处，在这种情况下，I/O 可以非常有效地重叠。

但是，在某些情况下，您很容易导致硬件抖动，因此我不认为这是一个应该掉以轻心的优化。

至于您添加的其他问题：

但是，如果 async-IO 在从不同磁盘读取/写入时真的可以加快速度（最高 2 倍），为什么这不是 CopyFile 的默认实现？（或者是吗？）

我不知道 的内部结构CopyFile()，但如果他们出于以下几个原因不这样做，我不会感到惊讶：

  1. 如果他们要使用一个额外的线程（或多个线程）来实现它，这可能对进程的侵入性比适当的要大（特别是如果该进程是单线程的）
  2. 如果他们尝试使用带有单个线程的异步 I/O 来实现它（正如ChrisW 所指出的那样），他们可能会导致抖动问题和提高性能一样。一般地确定什么时候你会得到好处而不是坏处可能并不容易。

这并不是说它不能或不应该完成（或者甚至没有完成——我不知道）——这些只是可能无法完成的几个可能原因。

于 2009-02-11T19:00:42.773 回答
1

这取决于，但通常不是，你的瓶颈将是磁盘 IO，你不能使用多线程使磁盘 IO 更快。

即使在极少数情况下，这也会起作用，但线程同步代码必须如此复杂以至于不值得。

于 2009-02-11T18:51:48.130 回答
1

如果您正在实现 CopyFile，那么您可以使用启动异步I/O的单个线程（这样一个线程可以同时启动/重新启动读取和写入），而不是使用多个线程（例如，一个线程用于读取，另一个线程用于写入） ，使用完成端口或其他。

为了提高性能，它可能完全在内核中实现。

于 2009-02-11T19:03:40.597 回答