Оптимизация: уменьшение размера файла в C или C ++ - PullRequest
2 голосов
/ 15 октября 2019

При выполнении компьютерного моделирования систем с n (например, 10000) частицами обычный рабочий процесс включает частое сохранение состояния системы через заданные интервалы. Это повлечет за собой запись в файл координат положения всех частиц (таким образом, 3 числа с плавающей запятой / каждая на строку, каждая строка для частицы), с некоторой информацией заголовка. Плавающая точность установлена ​​на фиксированное значение.

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

#include <iostream>
#include <fstream>

ofstream outfile(filelabel, ios::out);
outfile.precision(10);

outfile << "#Number of particles " << npart << endl;

for (int i=0; i<npart; i++){
outfile << particle[i].pos[0] << " " << particle[i].pos[1] << " " << particle[i].pos[2] << endl;
}

outfile.close();

Как правило, каждый такой файл для достаточно большой системы имеет размер 0,5–4 МБ, поэтому при частом его сохранении они в конце концов увеличиваются до большого размера. Поэтому я пытаюсь узнать, как можно оптимизировать размер моих файлов конфигурации до минимума, например, с помощью (2 мысли, которые приходят на ум):

  • Используя другой метод написания, а неОбязательно записывать файлы .txt.
  • Возможно сжатие (например, сжатие) данных перед записью в файл.

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


Небольшое добавление

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

Это актуально, поскольку, учитывая сохраненные файлы конфигурации, я склонен использовать Python для своих целей после анализа.

1 Ответ

1 голос
/ 15 октября 2019

Четыре предложения:

  1. Сохранение векторной информации (направление и смещение) должно занимать меньше места, чем сохранение координат XYZ. Но это означает сохранение ссылки на файл начального состояния, который требует больших вычислительных ресурсов.

  2. Предполагая, что описанный выше метод не практичен, тогда я все же рассмотрел бы использование векторов, если объем памяти большекритичнее, чем вычислительное время. Трехмерный вектор кодирует местоположение в 2 значениях вместо трех, поэтому даже если вы ссылаетесь на все местоположения из начала координат вместо предыдущего местоположения частицы, файлы должны быть почти на 30% меньше (при условии, что для сохранения векторов требуется более высокая точность).

  3. Насколько "случайны" координаты местоположения? Если есть какая-то корреляция, я бы сохранил данные в тексте и использовал бы метод сжатия файлов без потерь (например, предложение сохранить файлы на диск, который поддерживает сжатие файловой системы - что означает, что no работает для вас! Любые повторяющиеся строки символов будут сжаты и могут быть более эффективными, чем двоичный файл - если данные содержат повторяющиеся строки. Если координаты выглядят псевдослучайно, то сжатие (например, формат ZIP) ничего вам не даст, и вам следует использовать метод двоичного значения.

  4. При сохранении в двоичном формате (возможно, даже в текстовом) рассмотрите возможность преобразования значений с плавающей запятой в целые числа, которые соответствуют вашему объему / точности, перед записью их в файл. Это займет гораздо меньше места, чем хранение значений с плавающей запятой (или, что еще хуже, двойных). Это, конечно, предполагает, что требуемая точность может быть представлена ​​в пределах точности int (или long).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...