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

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

Более простой подход:

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

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

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

• Как быстро анализировать разделенные пробелами числа с плавающей запятой в C++? показаны эти подходы с эталонными тестами для чисел с плавающей запятой.

Обновление. Я изменил приведенную выше программу, чтобы преобразовать uint32_t в вектор.

При использовании примера входного файла размером 4,5 ГиБ^[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 ГБ, вам потребуется примерно 15 ГиБ ОЗУ только для хранения вектора (при условии отсутствия фрагментации при перераспределении): Синтаксический анализ 45 ГиБ завершается за 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 - большой файл не имеет этого преимущества

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

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). Вы можете установить буфер большего размера (например, 64 Кбайт или 256 Кбайт), используя setbuffer(3) и т. д. Но я предполагаю, что ваша (улучшенная) программа будет связана с вводом-выводом, а не с процессором. Затем вы можете поиграть с posix_fadvise(2).

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

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