Проблема с открытием файла большого размера

[Araks]

Здравствуйте, у меня проблема:
Пишу бинарный файл непосредственно с АЦП (80 кГц - 4 канала) больше минуты. Размер порядка 200-300 МБ, иногда до 700 МБ. Если файл меньше, то открывается нормально, если больше, то при открытии выдает ошибку, что не хватает памяти.
1) Подскажите как это можно обойти?
2) Есть ли какое ограничение на размер открываемого файла, если есть, то какое? И нельзя ли открывать файл "частями"?
3) Можно ли при сохранении файла автоматически при превышении его размера, не прерывая запись, создать новый файл и писать уже туда? (т.е. контролировать его размер)

Заранее спасибо.

[Konstantin Sumenko]

Ошибка при открытии или при непосредственном чтении из него?
По 3 пункту: можно. Ведешь учет размера файла (либо VI Get File Size, либо накапливаешь кол-во записанных байт), по превышению закрываешь используемый файл и открываешь новый но с другим именем- далее пишешь в него.

[Eugen Graf]

Чтение по частям было бы самое правильное. При чтении файла используй Set File Position, это что то вроде курсора-метки.
Ограничения нет, кроме размера RAM конечно

[toto]

Увы, ограничения все-таки есть. Оказывается нельзя создать массив любой длины, есть ограничение на кол-во элементов в массиве. Столкнулись с этим недавно, и убедились что проблема глобальная, то есть и в Delphi и СИ возникали исключения при создании огромного массива в виде: stack owerflow... Так что иногда LabVIEW может дать "не хватает памяти" занимая в памяти 400Мб, а иногда при 1,5 ГГб.

[mzu2006]

Delphi и С помещают некоторые структуры данных на стек. Это значит, что большие структуры данных нужно создавать в куче (heap). Но вроде бы должна как-то динамически перераспределять между стеком и кучей. Мне казалось, что на стек попадает только Handle сложной структуры (а то и указатель на handle), а сама структура идёт в кучу. toto, можешь привести воспроизводимый пример?

[Pavel]

Мне казалось, что на стек попадает только Handle сложной структуры (а то и указатель на handle), а сама структура идёт в кучу.

Куча - не резиновая и может закончиться.

[toto]

Выкладываю пример:

[crashwork]

В общем я тестил так.
1. Сначала протестил на одномерном массиве размером 10 млн, тип данных unsigned int8. По расчетной формуле размер занимаемого массива = 9,5 Мб. Однако в диспетчере задач приложение labview стало занимать на 30 Мб больше, то же самое показал и профайл.
2. При таком раскладе пример "тест массива" при 150-миллионном массиве отъел у меня около 470 метров оперативки (в диспетчере задач столько стало занимать приложение LabVIEW) после чего лаганул. На тот момент у меня цитирую "доступная физическая память" = 510 Мб.

Так что все закономерно, вот только почему массивы так много занимают? Что еще сохраняется в памяти помимо значений массива?

[toto]

Не совсм понял, что закономерно, у меня 3 Гига оперативки в компе. Размер массива из примера - 270Мб. При снятии Disable окна, LabVIEW при выполнении примера дает сообщение: Not enouth memory to complite this operation. После ОК - LabVIEW: Memory is full.

Сейчас в своем примере выкинул индикатор массива, вместо него нарисовал Sequence окно и выход Initialize Array завел на Sequence. В таком варианте VI сработала, но при попытке поставить Probe на провод от инициализации до пустого окна таже ошибка.

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

[mzu2006]

Очень интересная тема, toto. Мне кажется, дело здесь в фрагментации памяти. Вот мои доказательства:
1. Сейчас я испытываю этот на своём лаптопе. У меня 2Гб, вертится немало программ. Свободно около гига. Запускаю твой пример. Больше ~325Мб не выделить.
2. А если пойти другим путём: вместо двумерного массива сделать массив кластеров одномерных массивов. Тогда, одномерные, небольшие массивы не должны все в месте лежать в одной непрерывной области памяти.
проверяем: смог выделить 1 Гб, дальше не пробовал, система ушла в swap. Вот мой пример:

[toto]

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

[mzu2006]

Дело не в одномерности/двумерности а в том как хранит в памяти сложные структуры.

Но когда ты вместо массива выделяешь массив кластеров, состоящих из более мелких массивов, то давай посмотрим как выделяется пямть в этом случае:
во первых, выделяется кусок памяти под массив handles на кластера. непрерывный кусок памяти, 4 байта на handle.
во-вторых, на каждый массив, являющийся элементом кластера тоже выделяется своя область, непрерывная, но гораздо меньшего размера чем 1 большой. Т.е. теперь фрагментация памяти нам не помеха.

PS. Выделение 1 гб под двумерный массив кластеров из массивов прошёл также хорошо, как и под одномерный с тем же числом элементов.

[toto]

Да, так я и не спорю :) Похоже, причина как раз в непрерывном выделении куска памяти, а с фрагментацией эта проблема уходит.

[Pavel]

С этим трудно поспорить. Вдобавок народ на форумах поговаривает что в LV есть ограничение по размерности непрерывного массива в 1 гиг. Жаль, но похоже нет возможности определить максимальный размер блока выделяемой памяти который можно получить под свои нужды - DSMaxMem в винде не работает.

[toto]

Интересно, а в СИ нет такого ограничения разве? Мои ощущения подсказывают, что эти ограничения связаны не с самим LV а с СИ, как основой на которой и LV написан, а может даже глубже - с ОС.