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

[IORIK]

Igor_G писал:
Вопрос что обозначает это форматирование строки %.; ???

ответ - Это есть в Хелпе.

ответный вопрос: Я правильно представляю, что обведенное мной - это одно значение в hex?

Если я прав, вас такой вариант устроит?

Вы можете делать "своп" на диск, при этом кидая в утиль материнку или HD, но все равно не получите высокой скорости.
В лог-файле, который вам нужно разобрать, полный бардак. И основное время тратится на разбор этого бардака.
Если вам надо высокую скорость чтения - переделывайте прогу, которая создает этот лог-файл.

[IvanLis]

Что было, даже не смешно. Ушло больше суток.

вставка в массив

Что имеем сейчас:

это если сделать предварительную инициализацию массива

Ушло чуть более 16 сек и с памятью проблем нет. А на современном компе будет в разы быстрее. Если убрать Stop из цикла (ошибок пока не замечено было), то можно еще и распараллелить вычисления по ядрам процессора.
Я знал, что это в разы быстрее будет, но не думал что на столько. Да и интересно было сколько времени потратит при первом варианте.

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

IvanLis.vi

lv2010

(32.23 КБ) 149 скачиваний

Думаю что задача решена и цель достигнута .

[Igor_G]

Igor_G писал:
Вопрос что обозначает это форматирование строки %.; ???

ответ - Это есть в Хелпе.

Спасибо. Смотрел всегда здесь:
http://zone.ni.com/reference/en-XX/help ... om_string/
там этого нет.

ответный вопрос: Я правильно представляю, что обведенное мной - это одно значение в hex?

да.

Если я прав, вас такой вариант устроит?

Да. Интересно посмотреть. Мой VI отрабатывает на моем Ноутбуке приблизительно за 10сек.

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

Согласен. Но программа которая создает этотот файл, наз. PEAK Explorer и этим все сказано. http://www.peak-system.com/Home.59.0.html?&L=1

Вы можете делать "своп" на диск, при этом кидая в утиль материнку или HD, но все равно не получите высокой скорости.

Согласен, что на прямую увеличения скорости не получу хотя возможно, что и будет (Mой нем. колега делал эксперименты. Скорость обработки падает не линиально от загрузки RAM, а минимум в геометрической прогрессии). Т.е. свободный RAM основа скорости работы программы.
С утверждением - "в утиль материнку или HD" не согласен.
На чем оно основано? Мы каждый день сознательно пишем и стираем на HD пару десятков МВ и это нормальное рабочее использование РС (email; excel; word; jpg; vi; txt...). Я предложил к этому добавить еще пару десятков временных МВ.
Где проблема? Это не самое оптимальное решение, но оно должно работать.

[Igor_G]

Ушло чуть более 16 сек и с памятью проблем нет. А на современном компе будет в разы быстрее. Если убрать Stop из цикла (ошибок пока не замечено было), то можно еще и распараллелить вычисления по ядрам процессора.

У меня 2 ядерный процессор. LabVIEW загружает в моем варианте оба процесора одинаково.

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

Ни когда так не думал. Спасибо за активное участие в дискуссии и конструктивные предложения!
В споре рождается истина.

[Igor_G]

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

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

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

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

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

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

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

Не знаю какие требования были к участникам, но коды читать почти не возможно. Все знакомые нормы нарушены.
А жалко ведь действительно умные головы работали. П. Блюм со своей замечательной книгой "Стиль программирования" отдыхает.
Пожелание на будущие, чтобы участники пользовались ну хотя бы этими 44 правилами. Это не трудно, но приучает к порядку.
http://www.automationlabs.ru/forum/show ... 2%E8%EB%E0
П.С.
Может кто нибудь сказать какой алгорифм поиска в каком примере был реализован? С этой информацией тогда есть шанс понять, что и как реализовано.

[mzu2006]

Основным требованием тогда была скорость, а не читаемость кода. По моему, Использованы какие-то hash алгоритмы из ссылки на Wikipedia, что я приводил.

[Sevas]

Прав ли автор этого урока по поводу быстродействия программы на LV?
В 4-10 раз медленнее, чем текстовые языки звучит как-то слишком пессимистично.
http://www.fanatnauki.ru/index.php?opti ... &Itemid=25

[mzu2006]

Смотря как подходить к оптимизации, какие алгоритмы реализовывать. Иногда и код получается побыстрее плохо оптимизированного С++ кода. У меня был код, делающий вычисления. LabVIEW их распараллелил автоматом, а в C++ компиляторе нужно было включать OpenMP и играть с оптимизацией. Первый перенос кода в C++ привел к коду более медленному, чем код.
При управлении же устройствами основное время зачастую занимает ожидание ответа утсройства ...

[Igor_G]

Снова вопрос по оптимированию памяти.

Как пример показываю три VI.
Изходя из объяснений NI:
В первом VI требуется 16КВ памяти, где 8КВ занимает Array; 4КВ необходимо компайлеру для конвертирования DBL на SGL и 4КВ нужно для индикатора.
Во втором VI требуется 16КВ памяти, где 8КВ занимает Array; 4КВ необходимо компайлеру для конвертирования Array SGL и 4КВ нужно для индикатора.
В третьем VI должно требоваться 8КВ памяти (у меня 10КВ ?). Где 4КВ занимает Array и 4КВ Array индикатор.

Теперь вопрос.
Как самому замерить, где какие потери памяти идут и где конкретно???
Как без этой информации знать, где и что оптимировать? Вопрос уже не как, а именно где и что!
(О том как оптимировать написано достаточно хорошо здесь:
http://zone.ni.com/reference/en-XX/help ... ory_usage/ )

P.S.
С эти три простых VI показывают, как можно легко обмануться в своих ожиданиях. (Я во втором VI ни как не ожидал такого же плохого результата как в первом).

[Igor_G]

Здесь вот нашел интересную библиотеку labview\examples\memmon.llb.
Только вот сходу не пойму как бы ее применить к поставленому выше вопросу.

И еще один вопрос. Как программно заставить VI освобождать память?
Обращал уже кто нибудь внимание на то, что даже после закрытия VI LabVIEW не освобождает занятую им память? (Если говорить совсем точно то идет освобождение только той части памяти, которая отвечает за панель приборов. Т.е. незначительная часть освобождаеться). Чтобы очистить память нужно закрыть LabVIEW :(

Использование Request Deallocation Function не приносит НИ КАКОГО результата.
http://zone.ni.com/reference/en-XX/help ... t_dealloc/

[Igor_G]

Результат оптимизации.

Время работы VI сократилось в 10 раз. потребление памяти в 7 раз.
Сейчас VI отрабатывает выложенный файл за 1 сек. и с памятью проблем нет.
Не думаю, что я выжал еще все, что можно. Но результатом пока доволен ;о)

Не хватает инструментов замеряющих потребление памяти в проводниках. :(
Без них оптимизация памяти это работа на уровне слепого котенка.

[IORIK]

А зачем вы дублируете выделение 1D массива из двумерного?

[Igor_G]

Это делается для LabVIEW Compiler.
Согласен, что не привычно ;о)
Скажу чесно - до конца сам не понимаю (только предполагаю), как это интерпретирует LabVIEW Compiler.
Без этого Compiler делает полный клон Array и клонирует его в процессе обработки еще похоже не сколько раз. (Где, что и как сказать не могу. Т.к. не знаю как это можно замерить. И это очень сильно раздражает.)

Эту на первый взгляд "бредовую" идею взял из рекомендаций NI по использованию памяти.
http://zone.ni.com/reference/en-XX/help ... ory_usage/

[Igor_G]

Сейчас VI отрабатывает выложенный файл за 1 сек. и с памятью проблем нет.
Не думаю, что я выжал еще все, что можно. Но результатом пока доволен ;о)

На сегодняшний день результат на выложном файле 0,0564663067671Сек.
Добился его через работу по ссылкам на файл, использованием VIs из палитры File I/O VIs and Functions и inplace struktur.

Огромная благодарность mzu2006 !

[Boxa]

Здравствуйте, решил присоседится к оптимизации. Задача вроде простая: собрать данные по modbus и вывести на график. При первой реализации время цикла сбора было 450мс, сейчас смог получить 100мс. Возможно ли как-то добиться скорости цикла сбора 5-10мс?
Скорость передачи 19200 заявлена разработчиком со стороны МК, но в блоках LV где её задать не увидел и реальную скорость не знаю, но думаю если бы отличалась от заданной то обмен бы не работал. Связь выполнена следующим образом от МК по RS485 modbus ASCII подключен к MOXA, к ней я подключаюсь по TCP/IP.
За express при записи файла во втором цикле просьба сильно не пинать:)