在C++中高效读取大型文本文件

Question

我有一个非常大的文本文件（45GB）。每行文本文件都包含两个用空格分隔的64位无符号整数，如下所示：

4624996948753406865 10214715013130414417

4305027007407867230 4569406367070518418

10817905656952544704 3697712211731468838 ... ...

我想读取该文件并对这些数字执行一些操作。

我的C++代码：

void process_data(string str)
{
    vector<string> arr;
    boost::split(arr, str, boost::is_any_of(" \n"));
    do_some_operation(arr);
}

int main()
{
    unsigned long long int read_bytes = 45 * 1024 *1024;
    const char* fname = "input.txt";
    ifstream fin(fname, ios::in);
    char* memblock;

    while(!fin.eof())
    {
        memblock = new char[read_bytes];
        fin.read(memblock, read_bytes);
        string str(memblock);
        process_data(str);
        delete [] memblock;
    }
    return 0;
}

我对C++相对陌生。运行此代码时，我遇到了以下问题：

1. 由于以字节方式读取文件，有时块的最后一行对应于原始文件中未完成的行（例如，主文件中的实际字符串“4624996948753406865 10214715013130414417”变成了“4624996948753406865 10214”）。

2. 此代码运行非常缓慢。在64位Intel Core i7 920系统和6GB RAM中，一个块操作需要大约6秒钟。是否有优化技术可用于提高运行时间？

3. 在boost分割函数中，是否需要包括“\n”以及空格字符？

我已经了解了C++中的mmap文件，但我不确定这是否是正确的方法。如果是，请提供一些链接。

- Pattu

---

使用 eof 是不好的事情。 - molbdnilo

请编辑您的问题以显示编译命令（编译器版本和libstdc ++版本）。 - Basile Starynkevitch

保存数据以二进制形式而非十进制格式化文本，这样不是更简单吗？我在LabVIEW中做过类似的事情，读取二进制文件比解析文本文件快了约10倍（当然这取决于解析器的实现，但仍然如此）。额外的好处是，您不需要使用20*8=160字节来存储例如数字4624996948753406865 +空格，而只需8个字节。 - Gunther Struyf

Answer 1

我会将其重新设计为流式处理，而不是分块处理。

一个更简单的方法是：

std::ifstream ifs("input.txt");
std::vector<uint64_t> parsed(std::istream_iterator<uint64_t>(ifs), {});

如果您大致知道预期值的数量，使用std::vector::reserve可以提高速度。

---

或者您可以使用内存映射文件并迭代字符序列。

• 如何快速解析C++中的空格分隔浮点数？展示了这些方法及其针对浮点数的基准测试。

更新：我修改了上面的程序，将uint32_t解析到向量中。

当使用4.5GiB^[1]的样本输入文件时，该程序运行时间为9秒^[2]：

sehe@desktop:/tmp$ make -B && sudo chrt -f 99 /usr/bin/time -f "%E elapsed, %c context switches" ./test smaller.txt
g++ -std=c++0x -Wall -pedantic -g -O2 -march=native test.cpp -o test -lboost_system -lboost_iostreams -ltcmalloc
parse success
trailing unparsed: '
'
data.size():   402653184
0:08.96 elapsed, 6 context switches

当然，它至少会分配402653184 * 4 * byte = 1.5 gibibytes的内存。因此，当您读取一个45 GB的文件时，您需要大约15GiB的RAM来仅仅存储向量（假设没有重新分配时的碎片）：45GiB解析完成需要10分45秒：

make && sudo chrt -f 99 /usr/bin/time -f "%E elapsed, %c context switches" ./test 45gib_uint32s.txt 
make: Nothing to be done for `all'.
tcmalloc: large alloc 17570324480 bytes == 0x2cb6000 @  0x7ffe6b81dd9c 0x7ffe6b83dae9 0x401320 0x7ffe6af4cec5 0x40176f (nil)
Parse success
Trailing unparsed: 1 characters
Data.size():   4026531840
Time taken by parsing: 644.64s
10:45.96 elapsed, 42 context switches

相比之下，仅运行wc -l 45gib_uint32s.txt就需要大约12分钟（尽管没有实时优先级调度）。wc非常快速。

用于基准测试的完整代码

#include <boost/spirit/include/qi.hpp>
#include <boost/iostreams/device/mapped_file.hpp>
#include <chrono>

namespace qi = boost::spirit::qi;

typedef std::vector<uint32_t> data_t;

using hrclock = std::chrono::high_resolution_clock;

int main(int argc, char** argv) {
    if (argc<2) return 255;
    data_t data;
    data.reserve(4392580288);   // for the  45 GiB file benchmark
    // data.reserve(402653284); // for the 4.5 GiB file benchmark

    boost::iostreams::mapped_file mmap(argv[1], boost::iostreams::mapped_file::readonly);
    auto f = mmap.const_data();
    auto l = f + mmap.size();

    using namespace qi;

    auto start_parse = hrclock::now();
    bool ok = phrase_parse(f,l,int_parser<uint32_t, 10>() % eol, blank, data);
    auto stop_time = hrclock::now();

    if (ok)   
        std::cout << "Parse success\n";
    else 
        std::cerr << "Parse failed at #" << std::distance(mmap.const_data(), f) << " around '" << std::string(f,f+50) << "'\n";

    if (f!=l) 
        std::cerr << "Trailing unparsed: " << std::distance(f,l) << " characters\n";

    std::cout << "Data.size():   " << data.size() << "\n";
    std::cout << "Time taken by parsing: " << std::chrono::duration_cast<std::chrono::milliseconds>(stop_time-start_parse).count() / 1000.0 << "s\n";
}

---

^[1] 使用od -t u4 /dev/urandom -A none -v -w4 | pv | dd bs=1M count=$((9*1024/2)) iflag=fullblock > smaller.txt生成文件。

^[2] 显然，这是在linux的缓存中使用文件缓存的情况下进行的——大文件没有这个好处。

- sehe

---

我尝试了istream方法。我的系统有5GB的RAM和64位结构。在一个4.5GB文件上，istream代码只花了1分10秒。但当我在一个45GB文件上运行时，它以以下错误终止 - "terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc. Aborted"。我猜我得尝试mmap方法看看。 - Pattu

@Pattu 没问题，但 bad_alloc 表示你要么根本没有足够的内存来创建向量，要么由于碎片化而导致分配失败。尝试使用最终容量（或略多一些）调用 reserve()，避免不必要的重新分配。 - sehe

@Pattu 确保你有足够的内存。我在9秒钟内解析了4.5 GiB，而在不到11分钟的时间内解析了45 GiB（请参见代码的已更新答案）。 （注意，9s是由于缓存磁盘读取，当然，请考虑这些是实际的时间，而不是解析基准测试） - sehe

一个很好的回答。_wc -l 45gib_uint32s.txt_ 花了约12分钟，对吗？ - Maxim Egorushkin

@MaximEgorushkin 让我重现一下。生成大量数据需要大约30分钟时间。 - sehe

不幸的是，我的磁盘已经达到了30GiB的最大容量。因此，这里是30GiB的时间：1m12s。然而，这是在一个拥有32GiB RAM的系统上完成的。我还没有检查缓存效果。 - sehe

Answer 2

我只能猜测瓶颈在于：

string str(memblock);

-因为你在内存中分配了一个45MB长的段。

-您应该按行读取文件，如此处所述：

-逐行读取文件 -为了对程序进行分析，您可以在每行之间打印clock()，如下所述：

-轻松测量经过的时间

- Oren Kishon

---

每次循环重新分配45MB缓冲区也没有帮助。最好在循环外部分配一次，删除一次。请注意保持原文意思，同时使翻译更加通俗易懂。 - Paul Roub

这是45GB，不是MB。如果使用链接方法，需要几个小时。每行之间打印时间...？请不要... - starriet

Answer 3

你可以将文件映射到内存中，但这将依赖于平台（在Unix上是mmap，在Windows上是CreateFileMapping/MapViewIntoFile）；但如果在32位系统上，如果没有足够大的虚拟内存块剩余，可能会遇到问题（64位系统则不会有这个问题）。

内存映射应该比逐块从磁盘读取数据更快。

- MichaelMoser

---

该问题被标记为Linux。 - Basile Starynkevitch

Answer 4

在Linux上，使用C的<stdio.h>而不是C++流可能有助于提高性能（因为C++流是建立在FILE之上的）。您可以使用readline(3)或fgets(3)或fscanf(3)。您可以使用setbuffer(3)等设置更大的缓冲区（例如64K字节或256K字节）...但我猜您（改进后）的程序将受到I/O限制，而不是CPU限制。然后，您可以尝试使用posix_fadvise(2)。

您可能考虑使用内存映射mmap(2)和madvise(2)（也可参见fopen(3)的m模式）。另请参阅readahead(2)。

最后，如果您的算法允许，您可以将文件拆分为较小的部分，并在并行进程中处理每个部分。

- Basile Starynkevitch