慢读数百个文件答案

【问题标题】：Slow reading hundreds of files慢读数百个文件
【发布时间】：2013-02-04 08:42:29
【问题描述】：

我在处理更多二进制文件时遇到问题。我有很多很多文件夹，每个文件夹大约有 200 个 bin 文件。

我选择其中的 2 个目录，然后将这 2 个目录中的所有 bin 文件（它们的路径）保存到列表中，并使用此列表进行一些过滤。最后，列表中大约有 200 个 bin 文件。

然后我遍历所有过滤后的文件，并从每个读取的前 4x8 字节开始（我尝试了 FileStream 或 BinaryReader）。所有这些操作大约需要 2-6 秒，但只是第一次。下一次就够快了。如果文件长时间（大约 30 分钟）没有任何反应，则问题再次出现。

所以可能是关于缓存还是什么？

有人可以帮帮我吗？谢谢

【问题讨论】：

【解决方案1】：

文件的句柄很可能已被释放，这就是为什么在一段时间后 GC 会删除它们，并且需要更长的时间或只是操作系统将文件加载到 RAM 中，然后从那里为您提供它们这就是它更快的原因，但这不是问题，进程运行缓慢是因为它很慢，第二次更快并不重要，因为你不能依赖它。

我的建议是尽可能并行处理这些文件，以便能够充分利用手头硬件的全部功能。

首先隔离处理文件的代码，然后在Parallel.ForEach 中运行代码，看看是否有帮助。

【讨论】：

如果瓶颈是存储介质（例如硬盘驱动器），并行化将无济于事，这很有可能（我的意思是，它仍然会有所帮助，因为他可能正在执行 IO 和处理并行，是一个很好的建议，但可能无法真正解决他的问题）
你说得对，但这是他唯一有能力优化整个过程并减少总时间的地方。效果如何还有待观察。
@RB 虽然总的来说我同意简单的计算为我们提供 200 * 4 千字节的数据（仅从文件中读取 32 字节，但我们知道磁盘只能按扇区读取，最大为 4 千字节现在）每 2-6 秒为我们提供大约 800 KB 的数据。即使对于非常慢的磁盘，这也是非常少量的数据。目录碎片可能是一个问题 - 这是真的，但我不会完全否定代码优化的可能性。
@DavidGoshadze 我把它读作“所有操作总共需要 2-6 毫秒”。如果我们假设文件是随机分布的（作者建议它们是随机分布的），并假设每个文件的典型寻道时间为 10 毫秒（对于笔记本电脑来说可能更慢），那么这就是 2 秒，只是在寻道中。
是的，我称之为目录碎片。对目录进行碎片整理可能会有所帮助。

【解决方案2】：

一种可能性是您的驱动器将进入休眠状态（通常，驱动器将被配置为在 15-30 分钟后关闭）。这会增加一个显着的延迟（5 秒是一个典型的数字），因为硬盘驱动器正在恢复速度。

幸运的是，这是一件容易测试的事情。只需将断电时间设置为 6 小时，然后测试行为是否发生了变化。

【讨论】：