Эффективное чтение очень большого текстового файла в C++

У меня есть очень большой текстовый файл(45 ГБ). Каждая строка текстового файла содержит два 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;
}

Я относительно новичок в с.++ Когда я запускаю этот код, я сталкиваюсь с этими проблемами.

  1. из-за чтения файла в байтах иногда последняя строка блока соответствует незавершенной строке в исходном файле("4624996948753406865 10214" вместо фактической строки "4624996948753406865 10214715013130414417" основного файла).

  2. этот код работает очень медленно. Она занимает около 6secs запустить один блок операций в 64бит процессор Core система с i7 920 с 6 ГБ оперативной памяти. Есть ли какие-либо методы оптимизации, которые я могу использовать для улучшения среды выполнения?

  3. необходимо ли включать "n " вместе с пустым символом в функцию разделения boost?

Я читал о файлах mmap на C++, но я не уверен, что это правильный способ сделать это. Если да, пожалуйста, прикрепите некоторые ссылки.

4 ответов


Я бы перепроектировал это, чтобы действовать потоковым, а не на блоке.

более простым подходом было бы:

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

если вы знаете примерно, сколько значений ожидается, используя std::vector::reserve спереди может ускорить его дальше.


в качестве альтернативы вы можете использовать сопоставленный файл памяти и перебирать последовательность символов.

обновление я изменил вышеуказанную программу для разбора uint32_ts на вектор.

при использовании образца входного файла 4.5 GiB[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 ГБ, вам потребуется около 15 гиб ОЗУ просто храните вектор (при условии отсутствия фрагментации при перераспределении):в 45GiB разбора завершает в 10min 45s:

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 is молниеносная

Полный Код, Используемый Для Benchmark

#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 - большой файл не имеет этого преимущества


Я могу только догадываться, что узкое место находится в:

string str(memblock);

- потому что вы выделяете сегмент длиной 45 МБ в памяти.

вы должны прочитать файл строка за строкой, как описано здесь:

для профилирования вашей программы вы можете печатать clock () между каждой строкой, как описано в:


вы можете сопоставить файл с памятью, но это будет зависеть от платформы (в unix это будет mmap в windows CreateFileMapping/MapViewIntoFile); тем не менее, если в 32-битной системе у вас могут возникнуть проблемы, если не осталось достаточно большого блока виртуальной памяти (64-битные системы не будут иметь этой проблемы).

отображение памяти должно быть быстрее, чем чтение блока данных блоком с диска.


в Linux, используя C <stdio.h> вместо потоков C++ может помочь производительности (потому что потоки C++ построены выше FILE - s). Вы могли бы использовать readline (3) или fgets (3) или fscanf (3). Вы можете установить больший буфер (например, 64Kbytes или 256Kbytes), используя setbuffer(3) etc... Но я думаю, что ваша (улучшенная) программа будет связана с вводом-выводом, а не с процессором. Тогда вы могли бы играть с posix_fadvise(2)

вы можете рассмотрите возможность использования карт памяти mmap (2) & madvise(2) (см. Также m режим fopen (3)). См. также readahead (2)

наконец, если ваш алгоритм позволяет, можно csplit файлы в меньших частях и обрабатывать каждый из них в параллельных процессах.