Парсинг потоками

@CEBEP · Регистрация: 21.03.2010

Студворк — интернет-сервис помощи студентам

Здравствуйте.
У меня есть текстовый файл объёмом где-то 10-50 мегобайт. В нём в текстовом виде хранятся числа и строки в известном мне формате. Как наилучшим образом его считать и пропарсить?
То как это реализовано сейчас:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
UNVData::UNVData(std::string fileAdr)
{
    std::fstream f(fileAdr, std::ios::binary | std::ios::in);
 
    if(!f)
    {
        std::cerr << "Can't open file \"" << fileAdr << "\" licke binary!";
    }
    else
    {
        std::istringstream stream;
        f.seekg( 0, std::ios::end );
        std::ios::pos_type fSize = f.tellg();
        f.seekg( 0, std::ios::beg );
        
        char* file = new char[static_cast<unsigned long>(fSize) + 1];
        f.read( file, fSize );
        file[static_cast<unsigned long long>(fSize)] = 0;
 
        stream.str(file);
 
        delete[] file;
        
        /*Далее извлечение из потока по формату.*/
 
    }
}

Очевидные минусы:
1. Простой процессора во время считывания файла с диска
2. Использование массива просто чтобы перегнать данные в поток (по крайней мере время на переписывание информации из массива в поток и время на выделение массива).
Естественно, я знаю что можно просто брать данные из файлового потока, но, на сколько я понимаю, тогда информация будет считываться крошечными порциями. В такой ситуации жесткий диск должен работать очень неэффективно.

Буду рад услышать о более совершенных вариантах или узнать оправдательные аргументы в пользу высказанных выше.
Хочу отметить, что уже реализовал быстрый разбор файла в стиле Си, но хотелось бы попытаться выполнить задачу в рамках объектно-ориентированного подхода.

@Deviaphan · 15.10.2011, 08:07

1. Забей. У тебя один файл небольшого размера, потеря времени не существенна. Если делать параллельное считывание и парсинг, то код очень сильно усложнится, но время уменьшится не сильно.
2. Создай std::string, выдели в нём память, считай файл в эту строку и подключи её к потоку в виде буфера. Так избавишься от промежуточного массива.

@CEBEP · 15.10.2011, 08:17 **[ТС]**

2. так и сделаю

1. Я готов к трудностям. Это реализуется только многопоточностью или есть более простые методы?

Евгений М. · 15.10.2011, 08:21

Сообщение от CEBEP

Это реализуется только многопоточностью или есть более простые методы?

Сомневаюсь, что параллельные операции можно выполнять без использования многопоточности.

@Deviaphan · 15.10.2011, 08:44

Сообщение от CEBEP

Я готов к трудностям.

У тебя один файл или много?
Если один, то ты только потратишь время. Файл слишком маленький, чтобы распараллеливать считывание и парсинг. Если бы размер файла был сопоставим с объёмом оперативной памяти или больше её, то это имело бы смысл, но с файлом 50 мегабайт это не имеет смысла. На синхронизации потоков ты потратишь больше времени, чем выиграешь за счёт параллельной работы.
Если файлов много и ты реализуешь пакетную обработку, то всё несколько проще. Тебе нужно создать два буфера. Считываешь первый, запускаешь его парсинг и в это же время считываешь второй файл во второй буфер. Ждёшь завершения обеих операций, меняешь буферы местами и повторяешь. И чтение и парсинг лучше делать в отдельных потоках; в основной программе выполнять синхронизацию потоков.

Добавлено через 33 секунды

Сообщение от Евгений М.

Сомневаюсь, что параллельные операции можно выполнять без использования многопоточности.

MMX, SSE

Добавлено через 41 секунду
А учитывая мультискалярность...

@CEBEP · 15.10.2011, 08:44 **[ТС]**

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

@Deviaphan · 15.10.2011, 08:58

Для параллельной обработки одного файла, тебе придётся читать его кусками. Так же используешь два буфера. В один читаешь, второй обрабатываешь. Могут быть проблемы с "переносом", т.е. если часть данных останется в одном буфере, а продолжение в другом, так что подумай над этим. Возможно, будет удобнее использовать один буфер двойного объёма и "зациклить" его. Впрочем, всё зависит от того, как ты реализуешь парсер. Если длина данным фиксирована, то ты можешь точно высчитать размер буфера, чтобы не возникло описанной проблемы.
Наврятли имеет смысл делать буфер более 64 мегабайт, но зависит от скорости HDD и скорости парсинга. Т.е. тебе нужно примерно подобрать, чтобы скорость чтения блока размером N была равна времени парсинга блока такого-же размера.

@CEBEP · 15.10.2011, 11:42 **[ТС]**

Удивительно! думал что считать файл в строку целиком просто. До сих пор не смог, а занимаюсь этим с тех пор как написал что так и сделаю.

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
UNVData::UNVData(std::string fileAdr)
{
    std::fstream file(fileAdr, std::ios::binary | std::ios::in);
 
    if(!file)
    {
        std::cerr << "Can't open file \"" << fileAdr << "\" licke binary!";
    }
    else
    {
        file.seekg( 0, std::ios::end );
        std::ios::pos_type fSize = file.tellg();
        file.seekg( 0, std::ios::beg );
        
        std::string bufer;
        bufer.reserve(static_cast<std::basic_string<char, std::char_traits<char>, std::allocator<char>>::size_type>(fSize));
        std::ostringstream(bufer) << file.rdbuf();
 
        std::cout << bufer;
 
        std::istringstream stream(bufer);
 
        std::cout << bufer;
    }
}

Добавлено через 36 секунд
статик_каст - это шутка такая...

Добавлено через 3 минуты
В результате работы кода я получаю по прежнему пустую строку. fstream.read() шокировал тем что не может работать со строками. Я был уверен, что со стандартной библиотекой можно работать максимально просто используя стандартные объекты.... что-то я в печали...

@Deviaphan · 15.10.2011, 11:56

Сообщение от CEBEP

bufer.reserve(static_cast<std::basic_str ing<char, std::char_traits<char>, std::allocator<char>>::size_type>(fSize) );

C++
1
2
3
4
bufer.reserve(fSize+1);
f.read( &bufer.at(0), fSize );
bufer[fSize] = '\0';
std::istringstream stream(bufer);

Как бы всё...

Добавлено через 1 минуту
Операторы << и >> используются только для текстовых потоков, у тебя бинарные.

@CEBEP · 16.10.2011, 07:04 **[ТС]**

C++
1
2
3
4
bufer.reserve(fSize+1);
f.read( &bufer.at(0), fSize );
bufer[fSize] = '\0';
std::istringstream stream(bufer);

Этот способ никуда не годится. С одной стороны, память под строку действительно выделена, но длинна строки внутри класса после такой записи остаётся нулевой. Это приводит к тому, что при обращении к любому символу строки генерится ошибка а при попытке вывести такую строку выводится пустая строка. Здесь подходит

C++
1
2
3
std::string bufer;
bufer.resize(fSize + 1);
file.read( &bufer.at(1),  fSize  );

и присовение последнему символу '\0' тогда не нужно.
Кстати, << и >> в принципе годятся и для бинарного файла. Например,

C++
1
std::cout << file.rdbuf();

работает на ура.

@Deviaphan · 16.10.2011, 07:08

Точно. reserve выделяет память, но не меняет длину строки. Ступил чуток.)
Замени at(1) на at(0). С нуля индексация начинается.

Новые блоги и статьи Все статьи Все блоги /
[Owen Logic] Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ФедосеевПавел 14.03.2026 Поддержание уровня воды в резервуаре количеством включённых насосов: моделирование и выбор регулятора ВВЕДЕНИЕ Выполняя задание на управление насосной группой заполнения резервуара,. . .	делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью	SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .
Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .

@Deviaphan Делаю внезапно и красиво 1313 / 1228 / 72 Регистрация: 22.03.2011 Сообщений: 3,744
	15.10.2011, 08:07
	1. Забей. У тебя один файл небольшого размера, потеря времени не существенна. Если делать параллельное считывание и парсинг, то код очень сильно усложнится, но время уменьшится не сильно. 2. Создай std::string, выдели в нём память, считай файл в эту строку и подключи её к потоку в виде буфера. Так избавишься от промежуточного массива. 2

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	15.10.2011, 08:17 [ТС]
	2. так и сделаю 1. Я готов к трудностям. Это реализуется только многопоточностью или есть более простые методы? 0

@CEBEP 108 / 108 / 23 Регистрация: 21.03.2010 Сообщений: 445
	15.10.2011, 08:44 [ТС]
	файл наверняка будет один. но нельзя сказать каков его предельный размер. Возможно, там появятся цифры зашкаливающие за гигабайт. Впрочем, так или иначе, программу можно будет запустить на машине с оперативкой гигабайт в тридцать. 0

@Deviaphan Делаю внезапно и красиво 1313 / 1228 / 72 Регистрация: 22.03.2011 Сообщений: 3,744
	15.10.2011, 08:58
	Для параллельной обработки одного файла, тебе придётся читать его кусками. Так же используешь два буфера. В один читаешь, второй обрабатываешь. Могут быть проблемы с "переносом", т.е. если часть данных останется в одном буфере, а продолжение в другом, так что подумай над этим. Возможно, будет удобнее использовать один буфер двойного объёма и "зациклить" его. Впрочем, всё зависит от того, как ты реализуешь парсер. Если длина данным фиксирована, то ты можешь точно высчитать размер буфера, чтобы не возникло описанной проблемы. Наврятли имеет смысл делать буфер более 64 мегабайт, но зависит от скорости HDD и скорости парсинга. Т.е. тебе нужно примерно подобрать, чтобы скорость чтения блока размером N была равна времени парсинга блока такого-же размера. 1

@Deviaphan Делаю внезапно и красиво 1313 / 1228 / 72 Регистрация: 22.03.2011 Сообщений: 3,744
	16.10.2011, 07:08
	Точно. reserve выделяет память, но не меняет длину строки. Ступил чуток.) Замени at(1) на at(0). С нуля индексация начинается. 0