映射文件中的IO与使用文件流的IO

Question

我正在开发一个需要处理大量数据（以GB为单位）的应用程序。我不需要任何时候一次获取所有数据。可以对数据进行分段并仅在任何给定实例上处理（从而将其存储到内存中）分段。

我了解到，大多数需要处理大量数据的应用程序通常都是通过使用内存映射文件来完成的。进一步阅读有关内存映射文件的信息，我发现从内存映射文件读取数据/向内存映射文件写入数据的速度比普通文件IO快，因为我们最终使用了高度优化的页面文件算法来执行读写操作。

这是我的查询：

1. 使用文件文件IO的内存映射文件（我打算使用boost :: file_mapping并且正在Windows上）与使用文件流有何不同？
2. 与使用文件流相比（在7200 rpm的传统硬盘上），与存储文件映射的文件相比，我期望数据读/写的速度有多快？
3. 内存映射文件是处理如此大量数据的唯一方法吗？有更好的方法做到这一点（考虑我的用例）？

Answer 1

（免责声明：我是提议的 Boost.AFIO的作者）

使用内存映射文件（我计划使用 boost::file_mapping 并且我正在使用 Windows）进行文件 IO 与使用文件流有何不同？

大大简化的答案：

内存映射文件会延迟读取 4Kb 块，即当您第一次访问该 4Kb 页面时。当您请求数据时，文件流会进行读取。

更准确的答案：

内存映射文件使您可以直接访问文件 i/o 的内核页面缓存。您可以准确地看到内核为某些打开的文件缓存的内容。读取和写入直接到内核页面缓存 - 对于缓冲 I/O，速度不会更快。

与使用文件流（在传统硬盘 7200 rpm 上）相比，在内存映射文件的情况下，我可以期望数据读/写快多少？

可能不明显。如果您对差异进行基准测试，则可能是混淆因素，例如不同的缓存算法。硬盘驱动器太慢了，它永远是主导因素。

现在，如果您真的要问从系统负载点来比较两者的效率，那么内存映射文件的效率可能要高得多。STL iostreams 至少复制一次内存，而且在 Windows 上，大多数“立即”I/O 实际上是来自 Windows 内核为您的进程配置的小型内部内存映射的 memcpy，因此这是您读取的所有内容的两个内存副本，最少。

最有效的总是 O_DIRECT/FILE_FLAG_NO_BUFFERING 以及所有附带的问题，但很少有人会编写比操作系统更好的缓存算法。毕竟，他们花了几十年时间调整他们的算法。

内存映射文件是处理如此大量数据的唯一方法吗？有没有更好的方法来做到这一点（考虑到我的用例）？

内存映射文件允许内核使用通用缓存算法为您缓存一个非常大的数据集，该算法利用系统中的所有空闲内存。一般来说，对于大多数用例，您不会用自己的算法击败它们。