我正在开发一个程序，将要处理可能大小为100GB或更大的文件。这些文件包含了长度可变的多组记录。我已经完成了第一个实现，并且现在致力于提高性能，特别是在更有效地进行I/O操作方面，因为输入文件需要被扫描多次。
有没有一些使用mmap()和C++的fstream库读取块的经验法则？我的想法是从磁盘中读取大块到缓冲区，从缓冲区处理完整的记录，然后再读取更多。
mmap()代码可能会变得非常混乱，因为mmap的块需要位于页面大小的边界上（据我所知），而记录可能潜在地跨越页面边界。通过使用fstreams，我可以直接寻找记录的起点并开始读取，因为我们不受限于只读取位于页面大小的边界上的块。
在实际编写一个完整实现之前，如何在这两个选项之间做出选择？是否有什么经验法则（例如，mmap()速度是2倍）或简单测试？
mmap或read可能更快或更慢。
mmap比read具有更多的开销（就像epoll比poll具有更多的开销，后者比read具有更多的开销）。对于同样的原因，在某些处理器上更改虚拟内存映射是一项相当昂贵的操作，就像在不同进程之间切换一样昂贵。然而，
read时，您的文件可能已经很久没有被缓存了。如果您使用文件并立即丢弃它，则不适用此规则。(如果您尝试mlock页面只是为了将它们保留在缓存中，那么您正在试图智取磁盘缓存，这种愚蠢的行为很少有助于系统性能)。关于mmap/read的讨论让我想起了另外两个性能讨论:
一些Java程序员惊讶地发现非阻塞I/O通常比阻塞I/O慢，如果您知道非阻塞I/O需要进行更多的系统调用，这就是完全合理的。
一些其他网络程序员惊讶地发现epoll通常比poll慢，如果您知道管理epoll需要进行更多的系统调用，这就是完全合理的。
mmap与read()之间的许多事实仍然像以前一样正确，但是整体性能实际上只能通过在特定硬件配置上进行测试才能确定，而不能通过加总优缺点来确定。例如，“调用mmap的开销比读取(read)更大”是有争议的-是的，mmap必须向进程页表中添加映射，但是read必须将所有读取的字节从内核复制到用户空间。 - BeeOnRopemmap更快，我希望至少看到整个测试设备（源代码）与制表结果，以及处理器型号。 - Dietrich Eppmmap通常不会刷新TLB，除非在异常情况下（但是munmap可能会刷新）。我的测试包括微基准测试（包括munmap）和在真实应用场景中运行的“应用内”测试。当然，我的应用程序与您的应用程序不同，因此人们应该进行本地测试。甚至不清楚微基准测试是否更青睐于mmap：由于用户侧目标缓冲区通常留在L1中，因此read()也会大幅提升，而这在较大的应用程序中可能不会发生。所以说，“情况很复杂”。 - BeeOnRope这里已经有很多好的答案，涵盖了许多重要的观点，所以我只会添加一些直接上面没有涉及到的问题。也就是说，这个答案不应该被认为是正反两方面的全面总结，而是其他答案的补充。
在文件已经完全缓存1的情况下，mmap 可能看起来非常像魔法：
mmap 仅需要 1 次系统调用（可能）映射整个文件，之后不再需要更多的系统调用。mmap 不需要将文件数据从内核复制到用户空间。mmap 允许您“作为内存”访问文件，包括使用任何高级技巧对其进行处理，例如编译器自动向量化、SIMD 内部函数、预取、优化的内存解析例程、OpenMP 等等。如果文件已经在缓存中，似乎无法超越：您只需直接访问内核页缓存作为内存，它不能比这更快。
嗯，实际上可以。
mmap相比于read(2)（实际上是可比较的操作系统级系统调用，用于读取块）的一个主要隐藏成本是，对于新映射中访问的每个4K页面，您都需要执行“一些工作”，即使它可能被页面错误机制隐藏。
mmap整个文件需要缺页25百万次才能读取一个100GB的文件。现在，这些将是次要故障，但2500万个页面故障仍然不会非常快速。最佳情况下，一个次要故障的成本可能是数百纳秒。
mmap 严重依赖于TLB的性能现在，这些TLB缺失的实际成本严重取决于硬件的以下至少几个方面：(a)您有多少4K TLB条目以及其余的转换缓存如何执行(b)硬件预取如何处理TLB - 例如，预取是否会触发页面步进？(c)页面步进硬件的速度和并行性。在现代高端x86英特尔处理器上，页面步进硬件通常非常强大：至少有2个并行页面步进器，页面步进可以与持续执行同时发生，并且硬件预取可以触发页面步进。因此，在流式读取负载上，TLB对性能的影响相当低 - 这样的负载通常不管页面大小如何都会表现出类似的性能。然而，其他硬件通常要差得多！
read()避免了这些问题read()系统调用通常是C、C++和其他语言中提供的“块读取”类型调用的基础，它有一个主要缺点，每个N字节的read()调用必须将N字节从内核复制到用户空间。
malloc，并重复使用该缓冲区以进行所有 read 调用。在内核端，由于所有RAM通常使用少量非常大的页面（例如，在x86上为1 GB页面）线性映射，因此几乎没有4K页面或TLB未命中问题，因此在内核空间中非常高效地覆盖了页面缓存中的底层页面。
因此，基本上您有以下比较来确定单个读取大文件的速度：
mmap方法所暗示的每页额外工作是否比使用read()时从内核到用户空间复制文件内容的每字节工作更加昂贵？
在许多系统上，它们实际上大致平衡。请注意，每个都与硬件和操作系统堆栈的完全不同属性一起扩展。
特别是，当：使用mmap方法时，相对快速时：
...当以下情况发生时，read()方法相对更快：
read()系统调用具有良好的复制性能，例如内核端良好的copy_to_user性能。上述硬件因素在不同平台上变化非常大，甚至在同一系列中也是如此（例如，在x86代中，市场细分尤其如此），在架构之间（例如ARM vs x86 vs PPC）则完全不同。
操作系统相关的因素也在不断变化，双方都进行了各种改进，导致其中一种方法的相对速度大幅跃升。最近的列表包括：
MAP_POPULATE的情况下确实有助于mmap案例。arch/x86/lib/copy_user_64.S中添加了快速路径的copy_to_user方法，例如使用REP MOVQ当它很快时，这确实有助于read()案例。read()的方法是一个劣势，因为read()方法必须为每个“缓冲区大小”值的数据进行一次系统调用。您不能任意增加缓冲区大小以分摊此成本，因为使用大型缓冲区通常会表现得更差，因为您超过了L1大小，因此不断遭受缓存未命中的问题。mmap，您可以使用MAP_POPULATE映射大量内存区域，并且只需进行一次系统调用即可高效地访问它。
1 这基本上也包括文件一开始没有完全缓存的情况，但是操作系统的预读足够好，使它看起来像已经缓存（即，通常在您需要它的时候页面已经被缓存）。这是一个微妙的问题，因为预读的工作方式在 mmap 和 read 调用之间通常有很大的不同，并且可以通过“建议”调用进行进一步调整，如2所述。
2 ... 因为如果文件没有被缓存，您的行为将完全受到IO问题的支配，包括您的访问模式对底层硬件的影响程度 - 所有的努力都应该确保这样的访问尽可能地友好，例如通过使用 madvise 或 fadvise 调用（以及您可以进行的任何应用程序级别的更改以改善访问模式）。
3 例如，您可以通过按顺序将较小大小的窗口（例如100 MB）映射到内存中来解决这个问题。
4 实际上，事实证明使用MAP_POPULATE方法（至少在某些硬件/操作系统组合上）只比不使用它略快一些，可能是因为内核正在使用faultaround - 因此实际的次要故障数量减少了约16倍。
mmap将具有无法逾越的优势，因为它避免了固定的内核调用开销。另一方面，mmap也会增加TLB压力，并且在“热身”阶段（其中字节是在当前进程中第一次被读取，尽管它们仍然在页缓存中）可能比read更慢，因为它可能需要处理更多的工作，例如“故障绕过”相邻页面......对于某些应用程序，“热身”是最重要的！@CaetanoSauer - BeeOnRope主要的性能成本将会是磁盘IO。 "mmap()" 比 istream 更快，但由于磁盘IO会支配你的运行时间，所以差异可能不明显。
我尝试了Ben Collins的代码片段（见上/下文）来测试他的说法，“mmap() 要快得多”，但没有发现可测量的差别。请参阅我的评论。
除非您的“记录”非常大，否则我肯定不会建议单独 mmap 每个记录 - 这将非常慢，每个记录需要 2 个系统调用，并且可能会丢失磁盘内存缓存中的页面。
在您的情况下，我认为 mmap()、istream 和低级的 open()/read() 调用都差不多。对于这些情况，我建议使用 mmap()：
（顺便说一句 - 我喜欢mmap()/MapViewOfFile()。）
mmap更快。你可以编写一个简单的基准测试来证明它：
char data[0x1000];
std::ifstream in("file.bin");
while (in)
{
in.read(data, 0x1000);
// do something with data
}
对比:
const int file_size=something;
const int page_size=0x1000;
int off=0;
void *data;
int fd = open("filename.bin", O_RDONLY);
while (off < file_size)
{
data = mmap(NULL, page_size, PROT_READ, 0, fd, off);
// do stuff with data
munmap(data, page_size);
off += page_size;
}
显然，我省略了一些细节（例如如何确定文件结尾，如果您的文件不是page_size的倍数，但实际上它不应该比这更复杂。
如果可能的话，您可以尝试将数据分成多个文件，可以整个文件进行mmap()而不是部分进行mmap()（更简单）。
几个月前，我有一个未完成的boost_iostreams滑动窗口mmap流类的半成品实现，但没有人关心，我还忙于其他事情。最不幸的是，几周前我删除了旧的未完成项目存档之一，这是其中之一:-(
更新: 我还应该添加一个警告，那就是在Windows中，此基准测试看起来会非常不同，因为Microsoft实现了一个漂亮的文件缓存，它做了您在第一次使用mmap时要做的大部分工作。也就是说，对于频繁访问的文件，您可以只执行std :: ifstream.read()，它将像mmap一样快，因为文件缓存已经为您进行了内存映射，并且是透明的。
最终更新: 看吧，人们：在许多不同的操作系统和标准库，磁盘和内存层次结构的平台组合中，我无法确定系统调用mmap，作为一个黑盒子，将始终比read 快多少。尽管我的话可能被理解成这样，这并不是我的意图。最终，我的观点是，基于内存映射的i/o通常比基于字节的i/o更快；这仍然是正确的。如果您实验发现两者之间没有区别，那么对我来说唯一合理的解释是，您的平台在底层实现了有利于调用read性能的内存映射方式。要绝对确定您正在以可移植的方式使用基于内存映射的i/o，唯一的方法是使用mmap。如果您不关心可移植性，并且可以依赖于目标平台的特定特性，则使用read可能适合而不牺牲可测量的任何性能。
编辑整理回答列表： @jbl:
滑动窗口mmap听起来很有趣。你能再详细说一些吗？
当时我正在编写一个Git的C++库（即libgit ++），遇到了类似的问题：我需要能够打开大文件（非常大）而不会降低性能（就像使用std :: fstream一样）。
Boost :: Iostreams已经有一个mapped_file Source，但问题是它在mmapping整个文件，这将限制您到2^(wordsize)。在32位机器上，4GB还不够大。在Git中，您可能会遇到比这更大的.pack文件，因此我需要分块读取文件，而不必采用常规文件i / o。在Boost :: Iostreams的底层，我实现了一个Source，它更多地是另一种std :: streambuf和std :: istream 之间交互的视图。您也可以通过将std :: filebuf
mmap() 映射文件呢？如果一个 size_t 类型的变量能够容纳下文件的大小（在64位系统中很可能如此），那么可以直接一次性调用 mmap() 映射整个文件。 - Steve Emmerson很遗憾，Ben Collins失去了他的滑动窗口mmap源代码。将其放入Boost中会很好。
是的，映射文件速度更快。您实际上正在使用操作系统虚拟内存子系统将内存与磁盘关联起来，反之亦然。这样考虑：如果操作系统内核开发人员可以使其更快，他们会这样做。因为这样做可以使几乎所有事情都变得更快：数据库、启动时间、程序加载时间等等。
滑动窗口方法并不难，因为多个连续页面可以同时映射。因此，只要任何单个记录中的最大记录可以适合内存，记录的大小就无关紧要。重要的是管理记账工作。
如果记录不从getpagesize（）边界开始，则映射必须从上一页开始。映射区域的长度从记录的第一个字节开始（如果需要，则向下舍入到最近的getpagesize（）的倍数），到记录的最后一个字节（向上舍入到最近的getpagesize（）的倍数）。处理完记录后，您可以取消映射（unmap（））它并继续进行下一步。
在Windows下，使用CreateFileMapping（）和MapViewOfFile（）（以及GetSystemInfo（）获取SYSTEM_INFO.dwAllocationGranularity --- 而不是SYSTEM_INFO.dwPageSize）也可以正常工作。
mmap应该更快，但我不知道有多快。这在很大程度上取决于你的代码。如果你使用mmap，最好一次性映射整个文件，这会让你的生活变得更轻松。一个潜在的问题是，如果你的文件大于4GB（或者实际上限制更低，通常为2GB），你需要一个64位架构。因此，如果你正在使用32位环境，你可能不想使用它。
话虽如此，提高性能可能有更好的方法。你说“输入文件被扫描多次”，如果你可以一次读出来然后完成，那可能会更快。
我认为使用mmap的文件I/O会更快，但是在你对代码进行基准测试时，计数器示例不应该过于优化吗？
Ben Collins写道：
char data[0x1000];
std::ifstream in("file.bin");
while (in)
{
in.read(data, 0x1000);
// do something with data
}
char data[0x1000];
std::ifstream iifle( "file.bin");
std::istream in( ifile.rdbuf() );
while( in )
{
in.read( data, 0x1000);
// do something with data
}
此外，您还可以尝试将缓冲区大小设置为虚拟内存一页的大小，以防0x1000不是您机器上虚拟内存一页的大小... 在我看来，mmap文件I / O仍然胜出，但这样应该使事情更接近。
我记得几年前将一个包含树结构的大文件映射到内存中。与常规反序列化相比，我对速度感到惊讶，后者需要在内存中进行大量工作，例如分配树节点和设置指针。
因此，实际上我是在比较单个调用mmap（或其在Windows上的对应项）与许多（很多）调用operator new和构造函数调用。
对于这种类型的任务，与反序列化相比，mmap是无与伦比的。当然，对于此类任务，应该考虑使用boost的可重定位指针。
在我看来，使用mmap()函数“只是”减轻了开发人员编写自己的缓存代码的负担。在简单的“仅读取文件一次”的情况下，这并不难（尽管正如mlbrock指出的那样，您仍然可以节省将数据复制到进程空间中的内存），但如果您需要在文件中来回跳转或跳过某些部分，我相信内核开发人员可能比我更擅长实现缓存...
mmap 作为缓存的真正好处在于你可以简单地重新使用已经存在的页面缓存，这些缓存已经存在，因此你可以免费获得该内存，它还可以跨进程共享。 - BeeOnRope
mmap()比使用系统调用（例如read()）快2-6倍。 - mplattner