flatten to string или variant to data

Простейшие вопросы в области инженерной разработки
Blackman

Activity
leader
leader
Сообщения: 932
Зарегистрирован: 17 янв 2016, 15:02
Награды: 1
Версия LabVIEW: 6.1,8.5,20

Re: flatten to string или variant to data

Сообщение Blackman »

Порядок байтов native, host order более чем в 2 раза улучшает результаты для String
Вложения
Variant vs String Conversion 2.vi
(23.31 КБ) 85 скачиваний
rushonda
developer
developer
Сообщения: 289
Зарегистрирован: 26 фев 2016, 06:31
Версия LabVIEW: 18-20
Благодарил (а): 6 раз
Поблагодарили: 7 раз
Контактная информация:

Re: flatten to string или variant to data

Сообщение rushonda »

О, не ожидал что так быстро) Спасибо всем. Теперь то, что я понял: быстрее всего напрямую изображение передавать. Если выбирать между flatten и variant, то лучше variant.
Оставшиеся вопросы: кроме изображения я буду передавать команды и несколько параметров. Думаю что через кластер это сделать, правильно!?
rushonda
developer
developer
Сообщения: 289
Зарегистрирован: 26 фев 2016, 06:31
Версия LabVIEW: 18-20
Благодарил (а): 6 раз
Поблагодарили: 7 раз
Контактная информация:

Re: flatten to string или variant to data

Сообщение rushonda »

примет цикла с очередью
Вложения
пример
пример
Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3926
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2022
Благодарил (а): 11 раз
Поблагодарили: 126 раз
Контактная информация:

Re: flatten to string или variant to data

Сообщение dadreamer »

Vitekkz88 писал(а):dadreamer, да, я сначала туннели сделал. Потом явно внёс в цикл кластер.
А на других типах данных не пробовали пример с мистикой? Скажем, не на числовых, а на строковых?
Со строками пока не пробовал, проверю позднее. Хотелось бы для начала разобраться с тем, что есть. Все эти загадки так или иначе связаны с выделением памяти, что подтверждает инструмент Show Buffer Allocations:
вариант с туннелями
вариант с туннелями
вариант с регистрами
вариант с регистрами
Однако, как связать такую большую разницу в быстродействии на туннелях и на регистрах - хз :dntknw: Мне вообще не понятно, зачем выделять новый буфер на границе Flat Sequence?.. Чую, что-то тут темнит компилятор.

Похожая ерунда творится и в моём примере.
Array_Test_on_T-R.rar
lv2011
(13.14 КБ) 71 скачивание
Только у меня ситуацию усугубляет вызов CLFN. Для простоты я поместил в SubVI функцию очистки блока памяти ClearMem.
ClearMem.jpg
ClearMem.jpg (22.69 КБ) 2136 просмотров
В основном :vi: вот такой код:
2016-10-29_18-32-42.jpg
Меняю регистры на туннели и обратно (выделено зелёным). Получаю серьёзную разницу во временах выполнения программы: на регистрах - 9,5 мс, на туннелях - 70 мс. :shok: Если заменить вызов CLFN в SubVI на что-то встроенное наподобие Sort 1D Array, то времена выполнения сравняются и станут 70 мс. Вообще не улавливаю, как CLFN в подприборе может быть связан с туннелем/регистром в основной программе.

Дальше смотрим Buffer Allocations.
вариант с туннелями
вариант с туннелями
вариант с регистрами
вариант с регистрами
И опять происходит выделение памяти на границе Flat Sequence в случае использования туннелей. Правда, в моём случае оно, похоже, не связано с описанной проблемой, т.к. при замене CLFN на Sort 1D Array выделение остаётся, а времена изменяются. Пробовал задавать всевозможные опции выполнения, реентерантности и дебага в SubVI - толку ноль.

Вот такие пироги.

P.S.: я уже, конечно, встречался с тем, что :labview: в зависимости от ситуации компилирует разный код. Прямо до смешного: убираем "левый" проводок и программа начинает работать иначе (не совсем, но заметно). Но было это ровно один раз на специфическом железе. А тут - стабильная повторяемость на разных системах с разными версиями :labview: . Изображение
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Для чайников»