1

我刚在想...

在 I/O 操作中使用 c# 的多线程（假设将许多文件从 c 复制:\1\到c:\2\）会产生性能差异而不是执行操作顺序吗？

我与自己斗争的原因是最终的 IO 操作 - 是一项必须工作的项目。所以即使我并行工作 - 他仍然会按顺序执行这些复制订单......

或者我的假设是错误的？

在这种情况下，使用多线程复制有什么好处：

  • 复制许多小文件（总和 4GB）
  • 复制 4 个大文件（总和 4 gb，每个 1000 mb）

谢谢

4

3 回答 3

3

正如其他人所说，它必须根据具体的应用程序上下文来衡量。

但只是想提请注意这一点。每次复制文件时，都会检查对目标位置的写入访问权限，这很慢。

我们所有人都遇到过这样一种情况，您必须复制/粘贴一系列已经压缩的文件，如果您将它们再次压缩成一个大的ZIP文件，那么总压缩大小不会明显小于所有内容的总和，IO操作将执行得更快。（试试吧，如果你以前没有这样做，你会看到很大的不同）。

所以我会假设（再次必须在具体系统上进行测量，我的只是猜测）在单个磁盘上写入一个大文件，大量小文件会更快。

希望这可以帮助。

于 2012-06-29T21:30:45.290 回答
3

文件多线程与 CPU 无关，而与 IO 无关。这意味着适用完全不同的规则。不同的设备有不同的特点：

  1. 类似顺序 IO 的磁盘
  2. SSD 像顺序或并行随机 IO（我的有 4 个硬件“线程”）
  3. 网络喜欢许多并行操作来分摊延迟
于 2012-06-29T21:40:35.150 回答
2

我不是硬盘相关问题的专家，但也许这会给你一些启示：

Windows 使用的是 NTFS 文件系统。该系统不“喜欢”太多的小文件，例如 1kb 以下的文件。它将“神奇地”使 100 个 1kb 的文件重 400kb 而不是 100kb。处理大量“小”文件时也很慢。因此，复制一个大文件而不是复制许多相同权重的小文件会快得多。

另外，根据我个人的经验和知识，多线程不会加快复制许多文件的速度，因为实际的硬件磁盘就像一个单元一样，无法通过同时发送多个请求来加快速度（它会处理一个接一个。）

于 2012-06-29T21:29:44.573 回答