Если сохраняемый файл слишком велик
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Если сохраняемый файл слишком велик
я сталкиваюсь с этим почти каждый день
Последнее время, результаты многих многочасовых
и многодневных экспериментов представляют собой фаил,
слишком большой, чтобы целиком загрузить в буфер
таких распространенных у нас на фирме программ как MS ECХEL или
ORIGIN, они на каждом действии просто виснут.
Борюсь с этим следующими разными методами.
1. Разработал кучу различных критериев, методов и алгоритмов редуцирования
количества строк, записываемых в файл, не теряя при этом "важных" значений
измерений.
2. Написал специальный VI, который считывает большой файл по кусочкам и может
после просмотра записывать в отдельные файлы.
Сюда же, разные алгоритмы редуцирования "offline" уже готового файла
3. Автоматическое открытие следующего файла в процессе експеримента,
по достижению предыдущим, заданного оператором размера в Мегабайтах,
при этом время передается в следующий файл.
4. Внедрение "квазибинарных" и чисто бинарных форматов,
как здесь: http://www.labviewportal.org/viewtopic. ... 121#p24121
,что на первый взгляд,
вроде решает проблему, но ведь при дальнейшей обработке и просмотре все равно будет разворачиваться в буфере в ASKII формат и все подвешивать.
Я описал все так подробно, что скажете коллеги.
Я подозреваю, что все эти дела можно улучшить, знает кто пакет, который загружает не весь
файл в свой буфер, а по кусочкам. Может это "DIADEM"? Кто меня квалифицированно
проконсультирует на основании своего опыта?
Картинка это фрагмент типичного файла
экспериментальных данных.
Последнее время, результаты многих многочасовых
и многодневных экспериментов представляют собой фаил,
слишком большой, чтобы целиком загрузить в буфер
таких распространенных у нас на фирме программ как MS ECХEL или
ORIGIN, они на каждом действии просто виснут.
Борюсь с этим следующими разными методами.
1. Разработал кучу различных критериев, методов и алгоритмов редуцирования
количества строк, записываемых в файл, не теряя при этом "важных" значений
измерений.
2. Написал специальный VI, который считывает большой файл по кусочкам и может
после просмотра записывать в отдельные файлы.
Сюда же, разные алгоритмы редуцирования "offline" уже готового файла
3. Автоматическое открытие следующего файла в процессе експеримента,
по достижению предыдущим, заданного оператором размера в Мегабайтах,
при этом время передается в следующий файл.
4. Внедрение "квазибинарных" и чисто бинарных форматов,
как здесь: http://www.labviewportal.org/viewtopic. ... 121#p24121
,что на первый взгляд,
вроде решает проблему, но ведь при дальнейшей обработке и просмотре все равно будет разворачиваться в буфере в ASKII формат и все подвешивать.
Я описал все так подробно, что скажете коллеги.
Я подозреваю, что все эти дела можно улучшить, знает кто пакет, который загружает не весь
файл в свой буфер, а по кусочкам. Может это "DIADEM"? Кто меня квалифицированно
проконсультирует на основании своего опыта?
Картинка это фрагмент типичного файла
экспериментальных данных.
-
Pavel Krivozubov
- professor
- Сообщения: 4421
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Сама задумка хорошая. Я часто сталкивался с подобной проблемой и я думаю алгоритмы разбиения и прочее многие могут использовать для актуальных задач.
Но хотелось бы увидеть сам файл *.vi, если это возможно. Ну и желательно с примером того самого большого файла, который он открывает и пошаговой инструкцией как и что делать.
Но хотелось бы увидеть сам файл *.vi, если это возможно. Ну и желательно с примером того самого большого файла, который он открывает и пошаговой инструкцией как и что делать.
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
Konstantin Sumenko
- expert
- Сообщения: 1439
- Зарегистрирован: 17 июл 2008, 12:20
- Награды: 2
- Версия LabVIEW: 2010
- Откуда: Moscow
- Поблагодарили: 1 раз
- Контактная информация:
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Для очень больших массивов данных (гигабайты) писал собственный Viewer с возможностью экспорта частей в Excel/Origin. Всё равно, ты не будешь визуализировать сигнал, в котором несколько Gb данных. Объем реальной информации обычно меньше - делал фильтры "наиболее важных" данных.
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Я понял, что это проблема встречается довольноPavel Krivozubov писал(а):Сама задумка хорошая. Я часто сталкивался с подобной проблемой и я думаю алгоритмы разбиения и прочее многие могут использовать для актуальных задач.
Но хотелось бы увидеть сам файл *.vi, если это возможно. Ну и желательно с примером того самого большого файла, который он открывает и пошаговой инструкцией как и что делать.
часто, напоминает то, как Робинзон Крузо
строил слишком большую лодку и слишком далеко от берега...
Но перейдем к делу. Посылаю, вот, имитатор для генерации файла
результатов моих, скажем так, "общевойсковых" экспериментов в
ASCII-формате.
Что касается максимального размера файла?... определяется либо
"дуростью" ученого-теоретика, который "заказывает музыку",
либо упрямством сотрудников, которые хотят делать все сами и
стесняются получать консультации от более опытного в вопросах
измерительных систем товарища, то бишь меня, такой, видимо,
немецкий менталитет... может просто боятся что их уволят, не знаю...
Мой имитатор дописывает каждый следующий блок
данных в конец файла, точно так же, как в реальном эксперименте,
количество блоков и строк в блоке можно установить самому, можно нажать
на "Стоп" и раньше если еще не дошли до последнего блока.
В левой колонке стоит время, остальные 8 колонок результаты в физических еденицах(kN, mm, µm, °C, %, Volt, Amper и т.д.) Текстовый заголовок я не генерирую, здесь он не имеет никакого значения.
Чуть позже, сегодня, перешлю и простейший вьюер, который позволяет как то
работать с такими файлами даже гигабайтных размеров.
- Вложения
-
- file_macher.vi
- (75.1 КБ) 328 скачиваний
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Досылаю вьюер
Если работаем в шаговом режиме
нажимая кхопку "STEP", тогда "number of lines (all:-1)"
и "start of read offset (chars.:0 )" можно для каждого шага,
если нужно, переустанавливать. Остальное, думаю, интуитивно понятно,
да и в диаграмму можно заглянуть, если что.
Если работаем в шаговом режиме
нажимая кхопку "STEP", тогда "number of lines (all:-1)"
и "start of read offset (chars.:0 )" можно для каждого шага,
если нужно, переустанавливать. Остальное, думаю, интуитивно понятно,
да и в диаграмму можно заглянуть, если что.
- Вложения
-
- View_lage_file_Punkt_Koma.vi
- (138.08 КБ) 302 скачивания
-
Pavel Krivozubov
- professor
- Сообщения: 4421
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Ну что же коллега! Поздравляю!
Сгенерил файл 500 мегабайт. Открыл вьювером. Открывался 9 минут на машине 512 ОЗУ, 2500 МГц. При относительно сносной загрузке процессора (50%).
Утечек памяти - нет!
В общем результат вполне себе нормальный.
Мне кажется твоя работа станет первым кандидатом на Best LabVIEW Addon 2011, как ты на это смотришь?
Единственное чего я не понял, так это почему вьювер по завершении загрузки самовыключается?
Мне же с файлом еще работать, измерять там и прочее?
Ну и я бы лично добавил слайдер для более удобного перемещения по фреймам.
Сгенерил файл 500 мегабайт. Открыл вьювером. Открывался 9 минут на машине 512 ОЗУ, 2500 МГц. При относительно сносной загрузке процессора (50%).
Утечек памяти - нет!
В общем результат вполне себе нормальный.
Мне кажется твоя работа станет первым кандидатом на Best LabVIEW Addon 2011, как ты на это смотришь?
Единственное чего я не понял, так это почему вьювер по завершении загрузки самовыключается?
Мне же с файлом еще работать, измерять там и прочее?
Ну и я бы лично добавил слайдер для более удобного перемещения по фреймам.
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Спасибо за интерес к моей работе.Pavel Krivozubov писал(а): Сгенерил файл 500 мегабайт. Открыл вьювером. Открывался 9 минут на машине 512 ОЗУ, 2500 МГц. При относительно сносной загрузке процессора (50%).
Утечек памяти - нет!
.
Изменил чуть логику работы, "end of filе"
теперь VI не останавливает, просто я обычно всегда
просматривал в ручном степовом режиме. Он обеспечивает
не только последовательный о и произвольный доступ.
Открыл контрол задержки, можно уменьшить время но
загрузка процессора соответственно возрастет.
можно увеличить значение "number of lines (all:-1)"
файл будет считываться большими кусками, будет меньше обращений к диску,
какими именно определяет пользователь.
Мне в данном контексте не очень нравится слово "открывался"
скорей подходит "просматривался", так как в конце "открывания"
мы получаем "последний кадр".
Как бы не ввести кого нибудь в заблуждение.
- Вложения
-
- View_lage_file_Punkt_Koma.vi
- (139.76 КБ) 278 скачиваний
-
mzu2006
- doctor
- Сообщения: 2456
- Зарегистрирован: 16 авг 2008, 02:12
- Награды: 3
- Версия LabVIEW: 7.1 10 11 12
- Откуда: St-Petersburg (RU), Phila, Boston, Washington DC
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Я тоже сторонник перехода к бинарным файлам в этом случае. Почему?Konstantin Sumenko писал(а):А TDMS чем не устраивает?
Я протестировал на большом файле ~3Гб. Profiling показал, что основное время у меня тратится на чтение с диска.
оценочный расчёт: 3100 Мб, каждая строка приблизительно 130 символов, 9 чисел на строку. Если хватает точности single, то имеем 858 Мб на основной массив данных. Скорость работы при переходе к двоичному формату можно повысить в 3100/858 = 3.5 раза (от 1.5 минут до 25 секунд). Кроме того, 1Гб данных уже можно загрузить в LabVIEW за 1 раз.
А действительно большие файлы (>4Gb), программа не обработает вообще (у тебя кое-где использован u32 для указателя положения в файле + старые функции для чтения из файла). (В частности, на файле >4Gb программа просто зацикливается.)
Правила форума (Forum rules in Russian)
rm -rf /mnt/windows
rm -rf /mnt/windows
-
Pavel Krivozubov
- professor
- Сообщения: 4421
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Тогда мне не очень понятно. Каков смысл такого открытия?Jakob Brontfeyn писал(а): Мне в данном контексте не очень нравится слово "открывался"
скорей подходит "просматривался", так как в конце "открывания"
мы получаем "последний кадр".
Как бы не ввести кого нибудь в заблуждение.
Ведь после открытия пользователю нужен доступ к любой части файла, а не только к последней.
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Прийдется изложить, более подробно,
так как я подозреваю, что меня неправильно поняли
по пункту 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 строк.
Может, неожиданно для меня, возникнет большой интерес.
так как я подозреваю, что меня неправильно поняли
по пункту 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
- professor
- Сообщения: 4421
- Зарегистрирован: 07 фев 2008, 16:39
- Награды: 3
- Версия LabVIEW: 7.0 - 2013
- Откуда: г. Электросталь
- Благодарил (а): 24 раза
- Поблагодарили: 9 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Ну в общем мое мнение такое - для дальнейшей жизни этой работы, для участия её в BLVAddon 2011 и для того, чтобы она могла пригодиться другим, надо во первых сделать конечные экзешники (которые не завершаются разумеется с завершением цикла) и добавить перемещение по фреймам в виде слайдера или еще какой крутилки. И выложить всё это (экзешники и исходники генератора и вьювера на обозрение).
Правила форума
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
Developlabs - IT услуги - ждём Ваших заказов на написание программ
Новостной канал о LabVIEW и технологиях NI на Facebook
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Это уже исправлено здесьPavel Krivozubov писал(а):.....(которые не завершаются разумеется с завершением цикла) .
http://labviewportal.org/viewtopic.php? ... 336#p24287
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Спасибо за ценную информацию.mzu2006 писал(а): А действительно большие файлы (>4Gb), программа не обработает вообще (у тебя кое-где использован u32 для указателя положения в файле + старые функции для чтения из файла). (В частности, на файле >4Gb программа просто зацикливается.)
Формат U64 есть в более новых версиях LABVIEW,
я учту это замечание, перенесу в LV-2009 и исправлю.
А здесь оставлю ограничение < 4 Гб.
-
Jakob Brontfeyn
- expert
- Сообщения: 1729
- Зарегистрирован: 28 фев 2008, 11:01
- Награды: 6
- Благодарил (а): 1 раз
- Контактная информация:
Re: Если сохраняемый файл слишком велик
Так на каком все таки типе вьюера сосредоточимся?Pavel Krivozubov писал(а):... для дальнейшей жизни этой работы, для участия её в BLVAddon 2011 и для того, чтобы она могла пригодиться другим......
Или на обоих? суть в том, что типу "все в буфере"
есть альтернатива, переписал на нелабораторный комп, и
там спокойно смотри в ORIGIN.
А вот тут, несколько дней назад, прибегает ко мне,
один сотрудник. Он начал, не забив в проект часы,
на техническую поддержку, самостоятельно делать то,
что не умеет хорошо делать. ASCII-Файл получился 1,6 Гб.
И куда теперь с ним, в какой "ORIGIN" его засунуть,
программа сразу умерла от такого размера.
Проэкт горит...
Вот и дал я ему инструмент, чтобы нарезать на кусочки.
Приятно, иногда, почувствовать себя в роли Спасителя.
Жаль на это в материальном плане никак не прореагировали...
Наверное, я над обоими хорошо поработаю, сделаю побольше
сервиса, может есть какие то пожелания, предложения.
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
- 4 Ответы
- 958 Просмотры
-
Последнее сообщение jane_wild
-
- 12 Ответы
- 599 Просмотры
-
Последнее сообщение Sergey Puzanov