我必须在 C++ 程序中将大型 (2GB) 二进制文件中的二进制数据读入字符数组。第一次从我的 SSD 读取文件时，读取每个文件大约需要 6.4 秒。但是当再次运行相同的代码或者甚至在运行一个不同的虚拟程序之后时，它的功能与之前几乎相同，下一次读取每个文件只需要大约 1.4 秒。 Windows 任务管理器甚至在第二次、第三次、第四次……运行时显示的磁盘事件要少得多。所以，我猜是 Window 的文件缓存让我在下次填充阵列时免于等待来自 SSD 的数据。
在客户运行软件之前，是否有任何干净的选项可以将文件读入文件缓存？有比提前用 fread 加载文件更好的选择吗？我如何确保数据保留在文件缓存中直到我需要它？
或者我的文件缓存假设完全错误？对于这些不同的加载时间是否有其他(更好的)解释？
最佳答案
这里有根据的猜测: 您的文件缓存假设很可能是正确的。
能否在用户运行软件之前预加载文件？ 不直接。您的程序应该如何知道它将在接下来的几分钟内运行？
因此您可能需要辅助机制或技巧。 我在这里看到的选项是:
- 索引机制可让您更快、更有针对性地访问您的数据。如果您一次只需要这些数据中的一小部分信息，这会很有帮助。
- 尝试并行加载数据，因此即使它并没有真正变得更快，用户也会有这样的印象，因为他可以开始使用他拥有的数据，而其余的则在后台获取。
- 有一个随操作系统一起启动并预取所有内容的辅助工具，这样您就可以在需要时将其保存在内存中。 警告:这会产生严重的影响，因为您从一开始就为您的工具保留了大块 RAM 甚至 SSD 缓存(取决于实现)。仅当替代方案是世界末日时才考虑这样做……
您也可以尝试结合前两个选项。更快的数据可用性的关键是弄清楚按什么顺序读取什么，而不是试图一次性加载所有内容。 Divide and Conquer.
如果没有关于该问题的更多详细信息，则不可能提供更具体的解决方案。
关于c++ - 使用 C 第二次读取相同文件时的极端性能差异，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41145695/