flatten to string или variant to data
-
- leader
- Сообщения: 932
- Зарегистрирован: 17 янв 2016, 15:02
- Награды: 1
- Версия LabVIEW: 6.1,8.5,20
Re: flatten to string или variant to data
Порядок байтов native, host order более чем в 2 раза улучшает результаты для String
- Вложения
-
- Variant vs String Conversion 2.vi
- (23.31 КБ) 85 скачиваний
-
- developer
- Сообщения: 289
- Зарегистрирован: 26 фев 2016, 06:31
- Версия LabVIEW: 18-20
- Благодарил (а): 6 раз
- Поблагодарили: 7 раз
- Контактная информация:
Re: flatten to string или variant to data
О, не ожидал что так быстро) Спасибо всем. Теперь то, что я понял: быстрее всего напрямую изображение передавать. Если выбирать между flatten и variant, то лучше variant.
Оставшиеся вопросы: кроме изображения я буду передавать команды и несколько параметров. Думаю что через кластер это сделать, правильно!?
Оставшиеся вопросы: кроме изображения я буду передавать команды и несколько параметров. Думаю что через кластер это сделать, правильно!?
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: flatten to string или variant to data
Со строками пока не пробовал, проверю позднее. Хотелось бы для начала разобраться с тем, что есть. Все эти загадки так или иначе связаны с выделением памяти, что подтверждает инструмент Show Buffer Allocations: Однако, как связать такую большую разницу в быстродействии на туннелях и на регистрах - хз Мне вообще не понятно, зачем выделять новый буфер на границе Flat Sequence?.. Чую, что-то тут темнит компилятор.Vitekkz88 писал(а):dadreamer, да, я сначала туннели сделал. Потом явно внёс в цикл кластер.
А на других типах данных не пробовали пример с мистикой? Скажем, не на числовых, а на строковых?
Похожая ерунда творится и в моём примере. Только у меня ситуацию усугубляет вызов CLFN. Для простоты я поместил в SubVI функцию очистки блока памяти ClearMem. В основном вот такой код: Меняю регистры на туннели и обратно (выделено зелёным). Получаю серьёзную разницу во временах выполнения программы: на регистрах - 9,5 мс, на туннелях - 70 мс. Если заменить вызов CLFN в SubVI на что-то встроенное наподобие Sort 1D Array, то времена выполнения сравняются и станут 70 мс. Вообще не улавливаю, как CLFN в подприборе может быть связан с туннелем/регистром в основной программе.
Дальше смотрим Buffer Allocations. И опять происходит выделение памяти на границе Flat Sequence в случае использования туннелей. Правда, в моём случае оно, похоже, не связано с описанной проблемой, т.к. при замене CLFN на Sort 1D Array выделение остаётся, а времена изменяются. Пробовал задавать всевозможные опции выполнения, реентерантности и дебага в SubVI - толку ноль.
Вот такие пироги.
P.S.: я уже, конечно, встречался с тем, что в зависимости от ситуации компилирует разный код. Прямо до смешного: убираем "левый" проводок и программа начинает работать иначе (не совсем, но заметно). Но было это ровно один раз на специфическом железе. А тут - стабильная повторяемость на разных системах с разными версиями .
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
- 19 Ответы
- 2645 Просмотры
-
Последнее сообщение Artem.spb
-
- 3 Ответы
- 1729 Просмотры
-
Последнее сообщение Artem.spb
-
- 4 Ответы
- 1210 Просмотры
-
Последнее сообщение Юрий
-
- 4 Ответы
- 1077 Просмотры
-
Последнее сообщение BAS
-
- 4 Ответы
- 250 Просмотры
-
Последнее сообщение AndreyDmitriev