Если сохраняемый файл слишком велик

[Jakob Brontfeyn]

я сталкиваюсь с этим почти каждый день
Последнее время, результаты многих многочасовых
и многодневных экспериментов представляют собой фаил,
слишком большой, чтобы целиком загрузить в буфер
таких распространенных у нас на фирме программ как MS ECХEL или
ORIGIN, они на каждом действии просто виснут.
Борюсь с этим следующими разными методами.

1. Разработал кучу различных критериев, методов и алгоритмов редуцирования
количества строк, записываемых в файл, не теряя при этом "важных" значений
измерений.
2. Написал специальный VI, который считывает большой файл по кусочкам и может
после просмотра записывать в отдельные файлы.
Сюда же, разные алгоритмы редуцирования "offline" уже готового файла
3. Автоматическое открытие следующего файла в процессе експеримента,
по достижению предыдущим, заданного оператором размера в Мегабайтах,
при этом время передается в следующий файл.
4. Внедрение "квазибинарных" и чисто бинарных форматов,
как здесь: http://www.labviewportal.org/viewtopic. ... 121#p24121
,что на первый взгляд,
вроде решает проблему, но ведь при дальнейшей обработке и просмотре все равно будет разворачиваться в буфере в ASKII формат и все подвешивать.

Я описал все так подробно, что скажете коллеги.
Я подозреваю, что все эти дела можно улучшить, знает кто пакет, который загружает не весь
файл в свой буфер, а по кусочкам. Может это "DIADEM"? Кто меня квалифицированно
проконсультирует на основании своего опыта?

Картинка это фрагмент типичного файла
экспериментальных данных.

[Pavel Krivozubov]

Сама задумка хорошая. Я часто сталкивался с подобной проблемой и я думаю алгоритмы разбиения и прочее многие могут использовать для актуальных задач.
Но хотелось бы увидеть сам файл *.vi, если это возможно. Ну и желательно с примером того самого большого файла, который он открывает и пошаговой инструкцией как и что делать.

[Konstantin Sumenko]

А TDMS чем не устраивает?

[mzu2006]

Для очень больших массивов данных (гигабайты) писал собственный Viewer с возможностью экспорта частей в Excel/Origin. Всё равно, ты не будешь визуализировать сигнал, в котором несколько Gb данных. Объем реальной информации обычно меньше - делал фильтры "наиболее важных" данных.

[Jakob Brontfeyn]

Сама задумка хорошая. Я часто сталкивался с подобной проблемой и я думаю алгоритмы разбиения и прочее многие могут использовать для актуальных задач.
Но хотелось бы увидеть сам файл *.vi, если это возможно. Ну и желательно с примером того самого большого файла, который он открывает и пошаговой инструкцией как и что делать.

Я понял, что это проблема встречается довольно
часто, напоминает то, как Робинзон Крузо
строил слишком большую лодку и слишком далеко от берега...
Но перейдем к делу. Посылаю, вот, имитатор для генерации файла
результатов моих, скажем так, "общевойсковых" экспериментов в
ASCII-формате.
Что касается максимального размера файла?... определяется либо
"дуростью" ученого-теоретика, который "заказывает музыку",
либо упрямством сотрудников, которые хотят делать все сами и
стесняются получать консультации от более опытного в вопросах
измерительных систем товарища, то бишь меня, такой, видимо,
немецкий менталитет... может просто боятся что их уволят, не знаю...
Мой имитатор дописывает каждый следующий блок
данных в конец файла, точно так же, как в реальном эксперименте,
количество блоков и строк в блоке можно установить самому, можно нажать
на "Стоп" и раньше если еще не дошли до последнего блока.
В левой колонке стоит время, остальные 8 колонок результаты в физических еденицах(kN, mm, µm, °C, %, Volt, Amper и т.д.) Текстовый заголовок я не генерирую, здесь он не имеет никакого значения.
Чуть позже, сегодня, перешлю и простейший вьюер, который позволяет как то
работать с такими файлами даже гигабайтных размеров.

[Jakob Brontfeyn]

Досылаю вьюер
Если работаем в шаговом режиме
нажимая кхопку "STEP", тогда "number of lines (all:-1)"
и "start of read offset (chars.:0 )" можно для каждого шага,
если нужно, переустанавливать. Остальное, думаю, интуитивно понятно,
да и в диаграмму можно заглянуть, если что.

[Pavel Krivozubov]

Ну что же коллега! Поздравляю!
Сгенерил файл 500 мегабайт. Открыл вьювером. Открывался 9 минут на машине 512 ОЗУ, 2500 МГц. При относительно сносной загрузке процессора (50%).
Утечек памяти - нет!
В общем результат вполне себе нормальный.
Мне кажется твоя работа станет первым кандидатом на Best LabVIEW Addon 2011, как ты на это смотришь?
Единственное чего я не понял, так это почему вьювер по завершении загрузки самовыключается?
Мне же с файлом еще работать, измерять там и прочее?
Ну и я бы лично добавил слайдер для более удобного перемещения по фреймам.

[Jakob Brontfeyn]

Сгенерил файл 500 мегабайт. Открыл вьювером. Открывался 9 минут на машине 512 ОЗУ, 2500 МГц. При относительно сносной загрузке процессора (50%).
Утечек памяти - нет!
.

Спасибо за интерес к моей работе.
Изменил чуть логику работы, "end of filе"
теперь VI не останавливает, просто я обычно всегда
просматривал в ручном степовом режиме. Он обеспечивает
не только последовательный о и произвольный доступ.
Открыл контрол задержки, можно уменьшить время но
загрузка процессора соответственно возрастет.
можно увеличить значение "number of lines (all:-1)"
файл будет считываться большими кусками, будет меньше обращений к диску,
какими именно определяет пользователь.
Мне в данном контексте не очень нравится слово "открывался"
скорей подходит "просматривался", так как в конце "открывания"
мы получаем "последний кадр".
Как бы не ввести кого нибудь в заблуждение.

[mzu2006]

А TDMS чем не устраивает?

Я тоже сторонник перехода к бинарным файлам в этом случае. Почему?

Я протестировал на большом файле ~3Гб. Profiling показал, что основное время у меня тратится на чтение с диска.
оценочный расчёт: 3100 Мб, каждая строка приблизительно 130 символов, 9 чисел на строку. Если хватает точности single, то имеем 858 Мб на основной массив данных. Скорость работы при переходе к двоичному формату можно повысить в 3100/858 = 3.5 раза (от 1.5 минут до 25 секунд). Кроме того, 1Гб данных уже можно загрузить в LabVIEW за 1 раз.

А действительно большие файлы (>4Gb), программа не обработает вообще (у тебя кое-где использован u32 для указателя положения в файле + старые функции для чтения из файла). (В частности, на файле >4Gb программа просто зацикливается.)

[Pavel Krivozubov]

Мне в данном контексте не очень нравится слово "открывался"
скорей подходит "просматривался", так как в конце "открывания"
мы получаем "последний кадр".
Как бы не ввести кого нибудь в заблуждение.

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

[Jakob Brontfeyn]

Прийдется изложить, более подробно,
так как я подозреваю, что меня неправильно поняли
по пункту 2, всего пунктов 4, к обсуждению остальных
вернемся потом.
.............
2. Написал специальный VI, который считывает большой файл по кусочкам и может после просмотра "(добавлено мной) каждого кусочка"
записывать "их-эти кусочки" в отдельные файлы.
.............
Jakob: Мне в данном контексте не очень нравится слово "открывался"
скорей подходит "просматривался", так как в конце "открывания"
мы получаем "последний кадр".
Как бы не ввести кого нибудь в заблуждение.
........................................
Indey: Тогда мне не очень понятно. Каков смысл такого открытия?
Ведь после открытия пользователю нужен доступ к любой части файла, а не только к последней.
........................................
Павел ты говоришь о другом вьюере, который тоже у меня сделан
и успешно применяется на лабораторном компьютере,
если идет эксперимент, чтобы не подвесить другие приложения,
что приведет к активации в управляющей аппаратуре ватчдогтаймера,
и провалит весь эксперимент.
Он разбивает фаил данных на N кусков(константа в диаграмме), загружает последовательно по куску, не перегружая комп, добавляет в конец массива и выводит на граф, с некоторыми дополнительныму функциями для вьюинга.
Так, фирму и имя файла я забил, это испытания материала при высокой температуе (несколько сот градусов).
В зоне видимости по оси Y выделен параметр нагрузка (kN)
обрати внимание, одна курва затемнена, чтобы не мешала,
по Х оси видно, что эксперимент длится, примерно 50000 секунд(14 часов)
Размер файла мы тоже видим, примерно 28 МБ, что примерно
соответствует где то 290 000 строк. В эксперименте был применен
один из методов редуцирования, иначе строк в фаиле было бы,
где то в 5 раз больше. (но это будет потом другая тема)
Сделано определение по времени, количества циклов нагружения
до момента разрушения образца. Можно сделать также и другие
функции.
В буфере ВСЕ ДАННЫЕ, ну до 50, ну может до 100 МБ еще
как то может и пойдет, а дальше?
Вообще то, тема была "работа с большим количеством даных".
Для моих экспериментов 290 000 строк-это средний обьем данных.
Но, если этот тип вьюера тебе понравится больше, почему нет.
может кому-то 290 000 строк это уже очень, очень много,
для ECХEL, по моему, максимум допустимо 50 000 строк.
Может, неожиданно для меня, возникнет большой интерес.

[Pavel Krivozubov]

Ну в общем мое мнение такое - для дальнейшей жизни этой работы, для участия её в BLVAddon 2011 и для того, чтобы она могла пригодиться другим, надо во первых сделать конечные экзешники (которые не завершаются разумеется с завершением цикла) и добавить перемещение по фреймам в виде слайдера или еще какой крутилки. И выложить всё это (экзешники и исходники генератора и вьювера на обозрение).

[Jakob Brontfeyn]

.....(которые не завершаются разумеется с завершением цикла) .

Это уже исправлено здесь
http://labviewportal.org/viewtopic.php? ... 336#p24287

[Jakob Brontfeyn]

А действительно большие файлы (>4Gb), программа не обработает вообще (у тебя кое-где использован u32 для указателя положения в файле + старые функции для чтения из файла). (В частности, на файле >4Gb программа просто зацикливается.)

Спасибо за ценную информацию.
Формат U64 есть в более новых версиях LABVIEW,
я учту это замечание, перенесу в LV-2009 и исправлю.
А здесь оставлю ограничение < 4 Гб.

[Jakob Brontfeyn]

... для дальнейшей жизни этой работы, для участия её в BLVAddon 2011 и для того, чтобы она могла пригодиться другим......

Так на каком все таки типе вьюера сосредоточимся?
Или на обоих? суть в том, что типу "все в буфере"
есть альтернатива, переписал на нелабораторный комп, и
там спокойно смотри в ORIGIN.
А вот тут, несколько дней назад, прибегает ко мне,
один сотрудник. Он начал, не забив в проект часы,
на техническую поддержку, самостоятельно делать то,
что не умеет хорошо делать. ASCII-Файл получился 1,6 Гб.
И куда теперь с ним, в какой "ORIGIN" его засунуть,
программа сразу умерла от такого размера.
Проэкт горит...
Вот и дал я ему инструмент, чтобы нарезать на кусочки.
Приятно, иногда, почувствовать себя в роли Спасителя.
Жаль на это в материальном плане никак не прореагировали...
Наверное, я над обоими хорошо поработаю, сделаю побольше
сервиса, может есть какие то пожелания, предложения.