Оптимизация VI

[IvanLis]

Это что значит мы умудрились 4GB забить? Круто. Только как ума не приложу. A что делать тем более.
Помогите понять!

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

У Вас основная нагрузка идет именно при преобразовании строки в массив строк. А зачем это делать ??? Тем более вы разбиваете по пробелам (который используются для форматирования, а не только разделения данных), так что размер массива не определен. Получается, что 2D массив будет иметь строк (определяется файлом), а столбцов (максимальным количеством пробелов в строке). Будет много пустых, т.к. выравнивается по максимальному значению.
А реально у Вас столбцов шесть:
1. Message number
2. Time offset (in Milliseconds)
3. Bus
4. Type
5. Symbol/ID
6. Multiplexer/Variable/Data

Даже если Вы каждую строку разобьете на массив из шести строковых элементов, это уже будет значительный выигрыш. А если вы каждую строку опишите кластером и сразу будите делать преобразование типов (например Message number -> U32, Time offset -> DBL, Symbol/ID -> Enum (Список) и т.д. Строковым останется только последний столбец с данными, но лучше его тоже сразу разбирать), то выигрыш должен быть еще больше.

На мой взгляд нужно заморочится с регулярными выражениями и для парсинга строки использовать Match Regular Expression. Файл читать построчно.

[IvanLis]

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

IvanLis.vi

lv2010

(34.23 КБ) 134 скачивания

Работает не очень быстро, но это сам механизм RegEx. Хотя думаю, что быстрее, чем Ваш вариант .
Я не стал дожидаться окончания, но одну треть на моем стареньком компе (2Gb ОЗУ) разобрать удалось. Позже попробую.

Так что отпишитесь о результатах тестирования.
Ну и соответственно, как советовал раньше, желательно сразу преобразование типов делать.

[Igor_G]

IvanLis,
Большое спасибо за совет.
Опробую завтра (сегодня не дома).

[Igor_G]

http://ru.wikipedia.org/wiki/Искусство_программирования. Эти же алгоритмы расписаны в википедии по предыдущей ссылке. И один из них реализован на одной из прошлых олимпиад NI Russia,

Обычно результаты олимпиад open source.
Нельзя ли выложить это решение на форум? Уверен интересует многих.

[IORIK]

IvanLis, вы меня опередили.

К этой задаче можно подойти чуть по другому. Те элементы в строке, которые есть всегда (напр. "Message Number", "Time offset" и др.) можно сразу обработать "Scan for String", а все остальное разбирать с помощью "Match Pattern". В этом примере надо удалить последний элемент выходных массивов.

Optimize_Read1.vi

(17.46 КБ) 121 скачивание

Если у вас заголовок (первые строки в файле) занимает одно и то же кол-во строк/байт, то лучше всего перед циклом прочитать эти строки, тогда первый элемент выходных массивов будет соответствовать первому Message -> колонку "Message Number" можно исключить из обработки.

По поводу алгоритмов поиска: я честно говоря не знаю какой, из многочисленного списка способов, реализован в LabView для поиска в одномерном массиве.

[IvanLis]

Обычно результаты олимпиад open source.
Нельзя ли выложить это решение на форум? Уверен интересует многих.

А не всегда , например в прошлом году было так: Олимпиада по программированию в LabVIEW - 2011.

Но в этом случае помочь могу:

Поиск подмассива в двумерном массиве.zip

Решение - RUVIET
Решение - Антарес
Решение - Три полоски

(106.7 КБ) 118 скачиваний

Версию не знаю.

Это тройка победителей, но кто какое место занял не помню.

[Igor_G]

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

Спасибо. Интересная информация к размышлению.

А реально у Вас столбцов шесть:
1. Message number
2. Time offset (in Milliseconds)
3. Bus
4. Type
5. Symbol/ID
6. Multiplexer/Variable/Data

К сожалению это не совсем так.
Шестой столбец Multiplexer/Variable/Data имеет подобъекты. И их кол-во не постоянно и не известно (уже встречал от 0 до 128 подобъектов в Multiplexer/Variable/Data). Какое мах. кол-во подобъектов возможно ни кто не знает.
Пятый столбец тоже не всегда постоянный. Другие действительно имеют постоянный размер.

У Вас основная нагрузка идет именно при преобразовании строки в массив строк. А зачем это делать ??? Тем более вы разбиваете по пробелам (который используются для форматирования, а не только разделения данных), так что размер массива не определен.

Я не только разделяю данные, но и их таким образом форматирую. (Посмотрите файл в Word. Там очень хорошо видно, что файл имеет абсолютно не логичное кол-во пробелов перед объектами. Что и устраняеться через форматирование. По др. работать с таким файлом не возможно).

[IvanLis]

К сожалению это не совсем так.
Шестой столбец Multiplexer/Variable/Data имеет подобъекты. И их кол-во не постоянно и не известно (уже встречал от 0 до 128 подобъектов в Multiplexer/Variable/Data). Какое мах. кол-во подобъектов возможно ни кто не знает.
Пятый столбец тоже не всегда постоянный. Другие действительно имеют постоянный размер.

Дело не в размере, а в структуре.

Последний столбец нужно будет разбирать отдельно в зависимости от поля Symbol/ID. Но это другой вопрос.
Пока разговор идет о разборе файла данных на массив.

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

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

[Igor_G]

На мой взгляд нужно заморочится с регулярными выражениями и для парсинга строки использовать Match Regular Expression.

Все с него и начиналось. Потому-что просто, легко и удобно, но оооочень медленно. С Match Regular Expression при больших обьемах очень тормознутый механизм. Быстрей чем Scan From String Function пока мы ни чего не нашли. На мой взглад эта функция самый мощный инструмент во всей String палитрe (по разнобразию использования и производительности).
Пример тому Ваш VI. Он работает приблизительно в 185 раз медленнее чем мой вариант. (Screenshot и Profile прилагаются).

[Igor_G]

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

Жду с не терпением.

[IvanLis]

Жду с не терпением.

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

Но тут надо выбирать между надежностью и производительностью.
У меня например на стареньком ПК:

Система

Медленно, но верно идет к завершению:

Практически не пожирая памяти.

Пусть пока останется тайной, сколько времени на это ушло.
Но надеюсь Вам такое не часто проделывать приходится .

[Igor_G]

Пусть пока останется тайной, сколько времени на это ушло.
Но надеюсь Вам такое не часто проделывать приходится .

С такими объемами приходиться работать в первый раз. Но они будет только возрастать.
Поэтому поиск оптимального решения сейчас, в самом начале очень важен.
Открываться такие файлы будут часто. Открытие файла > 10сек. ни кто не акцептирует. Идеальное время < 3сек.
Программа должна быть надежной, производительной и гибкой.

У меня появилась одна идея, как можно обойти проблему с недостатком памяти.
Нужно то что загонялось в shift register (т.е. записывалось в RAM) писать на жесткий диск как времяный файл (который перед закрытием программы будет возможно удален). И его использовать дальше. (Оригинал не имею права изменять, а пользоваться им в том виде в каком он есть не возможно).
Теоретически должно работать. Тем самым RAM не загружаеться, доступ к информации становится медленее, но т.к. файл измеряеться только MB то это не должно быть сильно заметно. Формат файла придумать самому (я проверял Ваш VI с форматом .mig). Тем самым я исключаю возможность конфликта с какой-то др. программой и легко нахожу свои времямые файлы.
Так только будет результат отпишусь.

[Igor_G]

Обычно результаты олимпиад open source.
Нельзя ли выложить это решение на форум? Уверен интересует многих.

А не всегда , например в прошлом году было так: Олимпиада по программированию в LabVIEW - 2011.

Но в этом случае помочь могу:

Поиск подмассива в двумерном массиве.zip

Версию не знаю.

Это тройка победителей, но кто какое место занял не помню.

Спасибо. Действительно интересно.

[Igor_G]

Если у вас заголовок (первые строки в файле) занимает одно и то же кол-во строк/байт, то лучше всего перед циклом прочитать эти строки, тогда первый элемент выходных массивов будет соответствовать первому Message -> колонку "Message Number" можно исключить из обработки.

Информация к размышлению.
П.С.
Вопрос что обозначает это форматирование строки %.; ???
В офицальном описании этого нет :о(

[IvanLis]

С такими объемами приходиться работать в первый раз. Но они будет только возрастать.
Поэтому поиск оптимального решения сейчас, в самом начале очень важен.
Открываться такие файлы будут часто. Открытие файла > 10сек. ни кто не акцептирует. Идеальное время < 3сек.
Программа должна быть надежной, производительной и гибкой.

3 сек на сколько строк файла?

Скажу по секрету, работает прога уже больше суток.
Сейчас осталось около 7 тыс. строк, а за одну секунду обрабатывается примерно 2 строки.

У меня появилась одна идея, как можно обойти проблему с недостатком памяти.
Нужно то что загонялось в shift register (т.е. записывалось в RAM) писать на жесткий диск как времяный файл (который перед закрытием программы будет возможно удален).

Если ты зафигачишь десяток Гиг на винт. А потом его еще придется и считывать. То вряд ли это на много ускорит процесс.
Мне кажется, что результат в 50 т. строк в минуту, отличный результат.