Проблема с использованием памяти

[Lancelot]

Добрый день.
Столкнулся на днях с проблемой, о которой раньше и не подозревал:
Есть программа сбора данных, которая раз в час выбрасывает текстовый файл с данными (частота оцифровки 125 Гц, 8 каналов, размер файла 30 мб ). Есть другая программа, которая выполняет несложную обработку этих файлов (в результате получаем одну точку на канал за 10 минут) и отображает результаты обработки за последние 7 суток и сохраняет эти результаты в отдельный файл.
Так вот, после чтения нового файла и обработки полученных данных эти 30 МБ так и остаются в памяти (выяснилось это при чтении файлов другого размера) и вообще программа в памяти занимает порядка 300-400 МБ. Если же сразу загрузить файлы с результатами обработки, то потребляемая программой память будет порядка 30 мб.

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


Примечания: Исходный сигнал присутствует только в двух подВП (чтение данных -> обработка данных, один является вложением другого), далее все действия совершаются с результатами обработки

[IvanLis]

Так вот, после чтения нового файла и обработки полученных данных эти 30 МБ так и остаются в памяти

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

[Lancelot]

Чтение файла.

Обработка

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

Да, и еще, раньше читал файл как бинарный и преобразовывал его вручную (причем разными методами), но это не дало абсолютно ничего, так что решил использовать спредшит файл. Профайлер поставил все на свои места)

[IORIK]

Lancelot, пожалуйста конкретизируйте вашу задачу, зачем вам нужна оптимизация памяти?
300-400 Мб - нормальный расход памяти, если на компе стоит от 2 Гб и выше. Некоторые товарищи спокойно вешают комп на 16 Гиг и не морщатся.
Ваша программа сбора данных скидывает значения в текстовый файл. Для чего это нужно? В сформированном файле будет под 4 мильона числовых значений и вы их ни редактировать ни просматривать в текстовом редакторе не будете. Может сразу выходные данные писать в бинарный файл? Плюсы - 1) как минимум в 5 раз файлы по размеру станут меньше; 2) время на запись/чтение уменьшится; 3) при чтении вы сразу избавитесь от конвертации строки в числа; 4) память оптимизируете, т.к. в памяти текстовый файл не будет храниться.

Ваши программы построены так, что напрашивается следующая иерархия: программа сбора данных работает и крутится постоянно, создавая файлы данных. Эти файлы, по мере их накопления, копируются на другой комп и там уже идет постобработка. Конечно, эту программу можно запустить и на первом компе, но, как вы пишете, увеличивается размер занимаемой памяти. У вас вроде не такая уж сложная обработка, чтобы нельзя ее было включить в программу сбора данных. Тогда программа будет выдавать сразу 2 файла: исходный и обработку.

[Lancelot]

Все так, но есть определенные обстоятельства, которые не позволяют писать в бинарный файл. Не буду вдаваться в подробности - это организационные вопросы. Иначе был бы бинарник, сам не люблю с текстовыми файлами работать )
Программа обработки на самом деле является программой диагностики неисправностей инфразвуковой системы, именно поэтому ее нецелесообразно крутить на другом ПК (которого к тому же нет).

А расширение памяти и замена ПК - это гиблый путь. Если данных крутится на 27 Мб, то программа и должна кушать 27 МБ. Ну 50... максимум 100. А в последнее время система мониторинга расширилась и крутится уже две а то и три таких программы.

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

[IvanLis]

Чтение файла.
Обработка

Чтение вроде ОК, обработки не видно .
Попробуйте провести эксперимент, в режиме отладки обработать несколько файлов и локализовать участок кода, где происходит загруз памяти.
А уже потом работать над этим участком.

[dadreamer]

Lancelot, в обработке у вас есть SubVI "Чтение файла (бин.)", вы в нём тоже используете Spreadsheet File?

[IORIK]

Lancelot, я просто вам кидаю свои мысли, как я бы решал подобную задачу. Ваше право попробовать или откинуть .
Вам на закусь еще одна мыслишка: вы собственно знаете как работает функция "Read Spreadsheet File"?
На мой воспаленный идиотством мозг приходит такая вот идея: в начале берется текстовый файл и заглатывается в память целиком, как строка. А потом уже производится деление длин-длиной строки на элементы и их преобразование согласно формату.
А теперь вопрос: освобождается ли область памяти, выделенная на чтение текстового файла, сразу после окончания работы "Read Spreadsheet File"? или же все это отдано на уровень -го менеджера памяти?

[dadreamer]

освобождается ли область памяти, выделенная на чтение текстового файла, сразу после окончания работы "Read Spreadsheet File"?

Файл закрывается сразу же после отработки , т.к. в конце Read Spreadsheet File стоит Close File. А вот сколько хранится в памяти строковый буфер (и далее - массив формата DBL/I64/String), решает уже по ходу выполнения программы. Если нигде не используется, то утилизирует область памяти.

Можно попробовать инструмент Application -> Memory Control -> Request Deallocation, он должен ускорить очистку памяти от мусора. Но мне он особо никогда не помогал, корректнее было бы его назвать "LabVIEW, пожалуйста, начни убирать мусор".

[Borjomy_1]

Если надо уменьшить размер памяти, то самый логичный путь - отвязаться от полной загрузки файла в память, иначе есть принципиальная зависимость от объема файла.
Следует понимать, что это на диаграмме все так просто. Если вы посмотрите точки выделения памяти Tools->Profile->Show memory allocation..., вы увидите, что, по сути, копий файла в памяти может быть много, даже при простейшей обработке. А выделение и копирование 30Мб-ных фрагментов также тяжелая задача, причем совершенно бессмысленная. Ваши же задачи не требуют рандомного доступа к файлу (хотя и при рандомном чтении вовсе необязательно грузить файл целиком - манипуляции с памятью съедают выгоду от прямого доступа), поэтому имеет смысл совместить чтение из файла и обработку данных - это гораздо более оптимальное решение. А пример загрузки файла целиком в память (и к чему это приводит) у вас есть на рабочем столе - это программа "Блокнот", попробуйте открыть в нем 30Мб файл, вот так-же работает и ваша программа.

[Lancelot]

Расчеты в обработке

Насчет чтения файла целиком либо по частям были мысли, однако это сильно не поменяет ситуацию, поскольку обрабатывать приходится куски файла длительностью 10-30 минут. При том, что LabVIEW жрет память то по одному файлу, то по трем, хотелось бы все-таки разобраться где, как и зачем)
Кстати, если отключить буферизацию при открытии файла, то данные вообще не считываются(
IvanLis, а каким образом локализовать? Искусственно насоздавать подВП?
Выделение памяти происходит трижды: при чтении, при преобразовании и при выводе на индикатор (два последних хотелось бы объединить, но хз как).
А Request Deallocation пока не помог(

Проблема не в том, чтобы просто уменьшить потребление памяти, а в том, чтобы вовремя ее освобождать. Я часто работаю с такими данными, которые приходится читать большими кусками, поэтому хотелось бы научиться контролировать аппетиты своих программ

[ESeid]

Lancelot, мне приходится обрабатывать записанные фильмы, которые могут достигать и 10, и 20 Гб. Открывать их даже по частям - дело долгое и непродуктивное. Поэтому я записываю их в бинарной форме, и открываю сериями последовательных фреймов. Посчитать размеры окна открытия: точка входа, количество считанных бит - дело простое и автоматическое, преобразование типа данных в нужную вам форму и назад - еще проще. Мой опыт говорит, что не имеет смысла открывать более 8-10 Мб сразу, если предстоит некая их обработка - очень тяжело контролировать обьем расходуемой памяти, а растет он быстро, и время исполнения - тоже. Важное замечание: после извлечения из файла очередной порции файл необходимо закрыть, иначе возникают самые разные проблемы. Не в обычной работе, а в случае аварийного прерывания, или зависания, особенно при отладке - запросто можете потерять файл, причем, вроде бы, включенный только на чтение.

[dadreamer]

Можно попробовать из пакета OpenG для работы с большими файлами: OpenG -> OpenG Large File -> LF Read File / LF Seek File, вдруг с ними будет меньше памяти кушать.

[Borjomy_1]

Lancelot,

поскольку обрабатывать приходится куски файла длительностью 10-30 минут

А чем вас не устраивает считывать данные внутри циклов? Вычитали строку и тут-же ее посчитали.

[Lancelot]

Lancelot,

поскольку обрабатывать приходится куски файла длительностью 10-30 минут

А чем вас не устраивает считывать данные внутри циклов? Вычитали строку и тут-же ее посчитали.

Я же говорю, мне необходимо обрабатывать массив данных, который является от 1/6 до 1/2 файла. Но лучше целиком, потому что при фильтрации переходный процесс будет только в начале. Да и опять же, сколько нужно повторять: не всегда бывает возможность читать файл фрагментами (делать это легко, при возможности я это использую, как и бинарные файлы). В данный момент меня интересует вопрос работы с памятью. Я достаточно думал над архитектурой программы и измерительного комплекса в целом и имею основания делать именно так, как делаю. Чтение файлов кусками принципиально не решает проблему, а лишь ослабляет ее последствия, поэтому давайте больше не будем об этом.