用C ++有效地阅读一个非常大的文本文件

我有一个非常大的文本文件(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 10214”,而不是主文件的实际string“4624996948753406865 10214715013130414417”)中的未完成行。

  2. 这段代码运行得非常慢。 大约需要6秒,在一个带有6GB RAM的64位Intel Core i7 920系统中运行一个块操作。 有没有我可以用来改善运行时间的优化技术?

  3. 是否有必要在boost分割函数中包含“\ n”以及空白字符?

我已经阅读了有关C ++的mmap文件,但我不确定这是否是正确的方式。 如果是,请附上一些链接。

Solutions Collecting From Web of "用C ++有效地阅读一个非常大的文本文件"

我会重新设计这个流式,而不是一个块。

一个更简单的方法是:

 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 *字节= 1.5千兆字节。 所以当你阅读一个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 od -t u4 /dev/urandom -A none -v -w4 | pv | dd bs=1M count=$((9*1024/2)) iflag=fullblock > smaller.txt

[2]显然,这是在linux上的缓冲区缓存中缓存的文件 – 大文件没有这个好处

我只能猜测瓶颈在于:

 string str(memblock); 

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

您应该逐行读取文件,如下所述:

  • 逐行读取文件

为了分析你的程序,你可以在每行之间打印clock(),如下所示:

  • 轻松测量经过的时间

你可以将内存映射到内存中,但是这将取决于平台(在unix上,这将是在Windows CreateFileMapping / MapViewIntoFile的mmap); 即使在32位系统中,如果没有足够大的虚拟内存块(64位系统不会有这个问题),也可能会出现问题。

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

在Linux上,使用C <stdio.h>而不是C ++流可能会有助于性能(因为C ++流是在FILE -s之上构建的)。 你可以使用readline(3)或fgets(3)或fscanf(3) 。 你可能会使用setbuffer (3)等设置一个更大的缓冲区(例如64K字节或256K字节)。但是我想你的(改进的)程序是I / O绑定的,而不是CPU绑定的。 那么你可以玩posix_fadvise(2)

您可以考虑使用内存映射mmap(2) & madvise(2) (另请参阅m mode for fopen(3) )。 另见预读(2)

最后,如果你的算法允许的话,你可以把这些文件分割成更小的部分,并且在并行进程中处理每个文件。