Все вещи равняются тому, что самый быстрый путь к выходным данным к диску в C++?

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

• нормальный ввод-вывод потока C ++
• нормальный ввод-вывод потока с использованием ostream :: write ()
• использование библиотеки CI / O
• использование системных вызовов, таких как as write ()
• asynch I / O

И я бы остановился, когда нашел решение, которое было достаточно быстрым.

Самый быстрый способ - асинхронный ввод-вывод на основе завершения.

Предоставляя ОС набор данных для записи, которые она фактически не записала при возврате вызова, ОС может переупорядочить их, чтобы оптимизировать производительность записи.

API для этого зависит от ОС: в Linux он называется AIO ; в Windows это называется Порты завершения .

Текстовый формат означает, что он предназначен для употребления людьми. Скорость, с которой люди могут читать, намного, намного ниже скорости любого разумного метода вывода. Где-то есть противоречие. Я подозреваю, что «вывод должен быть в текстовом формате».

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

Пункт 23 «Рассмотрение альтернативных библиотек» Скотта Мейерса «Более эффективный C ++» предлагает использовать stdio вместо iostream, если вы предпочитаете скорость, а не безопасность и расширяемость. Стоит проверить.

Создавать (большие) блоки данных, которые могут быть последовательно записаны, и использовать асинхронный ввод-вывод.

Точное профилирование будет болезненным, прочтите несколько статей по этой теме: scholar.google.com .

Отображение файла в память (то есть с использованием файла сопоставления памяти ), а затем просто memcopy -ing данных, есть действительно быстрый способ чтения / записи.

Вы можете использовать несколько потоков / ядер для записи в данные, и ОС / ядро ​​будет синхронизировать страницы с диском, используя те же процедуры, что и для виртуальной памяти, которые можно ожидать, которые будут оптимизированы до чертиков и обратно. , более или менее.

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

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

Edit: related question, and Wikipedia article on memory mapped files - both mention performance benefits.

Откройте файл в двоичном режиме и запишите «неформатированные» данные на диск.

fstream myFile;
...
myFile.open ("mydata.bin", ios:: in | ios::out | ios::binary);
...
class Data {
    int      key;
    double   value;
    char[10] desc;
};

Data x;

myFile.seekp (location1);
myFile.write ((char*)&x, sizeof (Data));

РЕДАКТИРОВАТЬ: OP добавил: «Выходные данные должны быть в текстовом формате, независимо от того, разделены ли они табуляцией или запятой». ограничение.

Если ваше приложение ограничено ЦП, форматирование вывода - это накладные расходы, которые вам не нужны. Двоичные данные намного быстрее записываются и читаются, чем ascii, они меньше на диске (например, с двоичными данными записано меньше байтов, чем с ascii), и, поскольку они меньше, они быстрее перемещаются по сети (включая смонтированную сеть. файловая система). Все индикаторы указывают на бинарность как на хорошую общую оптимизацию.

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

Переход от двоичного кода к ascii, а затем придирки относительно относительной производительности printf по сравнению с iostreams, вероятно, не лучшее использование вашего времени.

Быстрый метод заключается в использовании двойной буферизации и нескольких потоков (по крайней мере, двух).

Один поток отвечает за запись данных на жесткий диск. Эта задача проверяет буфер и, если он не пуст (или возможно другое правило), начинает запись на жесткий диск.

Другой поток записывает форматированный текст в буфер.

Одной из проблем производительности жестких дисков является время, необходимое для того, чтобы набрать скорость и установить головку в нужное место. Чтобы этого не происходило, задача состоит в том, чтобы постоянно записывать на жесткий диск, чтобы он не останавливался. Это непросто и может включать в себя вещи, выходящие за рамки вашей программы (например, другие программы, работающие в то же время). Чем больше кусок данных, записанный на жесткий диск, тем лучше.

Еще одна проблема - поиск свободных мест на жестком диске для размещения данных. Фрагментированный жесткий диск будет работать медленнее, чем отформатированный или дефрагментированный.

Если переносимость не является проблемой, вы можете проверить свою ОС на наличие API, которые выполняют блочную запись на жесткий диск. Или можно спуститься ниже и использовать API, выполняющий запись непосредственно на диск.

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