文件通过多个线程复制优化

Question

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

编辑：为了澄清，假设您正在实施CopyFile（src，tgt）。在某些情况下，您可以使用多个线程来加快速度，这似乎是合乎逻辑的。

修改更多想法：

当然，这取决于相关的硬件/存储。

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

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

Answer 1

如果你不小心，你可以慢一点。磁盘擅长串行访问，如果你有多个线程，磁盘头将遍布整个地方。现在，如果您正在处理高性能SAN，可能会提高性能，SAN将处理优化磁盘访问。

Answer 2

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

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

执行高性能文件复制非常疯狂，您必须考虑缓存行为和网络驱动程序限制等问题。

所以总是使用操作系统文件复制功能（在Windows下是FileCopyEx）并且不要自己编写。

Answer 3

我想不会。 CPU没什么可做的。

Answer 4

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

但是，在某些情况下，您可能会轻易导致硬件颠簸，因此我认为这不是一个应该轻易进行的优化。

至于您添加的其他问题：

  

但是如果async-IO可以真正加速   事情（最多2倍）时   从不同的磁盘读/写，   为什么这不是默认值   CopyFile的实现？ （或者是   吗？）

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

1. 如果他们使用一个额外的线程（或多个线程）来实现它，这个线程可能对某个进程的干扰比适当的更多（特别是如果该进程是单线程到这一点）
2. 如果他们尝试使用具有单个线程的异步I / O来实现它（因为ChrisW indicated是可能的），他们可能会因为提高性能而导致颠簸问题。一般来说，确定何时获得利益而不是损害可能并不容易。

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

Answer 5

这取决于，但通常不会，您的瓶颈将是磁盘IO，并且使用多个线程无法使磁盘IO更快。

即使在非常罕见的情况下，这将起作用，线程同步代码也必须如此复杂，以至于不值得。

Answer 6

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

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