Есть система сбора данных, которая производит несколько измерений, накапливает их и попутно отображает на XY Graph. Каждое измерение - это кластер с массивами переменной длины. На приведенном рисунке-примере видно, что каждые 3 измерения предыдущие массивы измерений отбрасываются, и цикл накопления-отображения повторяется. На XY Graph соответственно обработаются наборы измерений: 0, 0+1, 0+1+2 и по новой.
Массивы измерений имеют переменную длину, и как правило большое кол-во точек, количество измерений постоянно (в примере 3).
На рисунке приведены две схемы накопления данных:
1. Через build array. При каждом измерении массив кластеров расширяется, затем при перезапуске измерений перезаписывается новым 0-ым кластером измерений. Массив пишется в shift register и подается как есть на XY Graph
2. Через очередь. Каждое измерение просто добавляется в очередь, при перезапуске измерений предварительно очищается. Для отображения на XY Graph используется Get Queue Status с выгрузкой в массив всех элементов очереди без очистки.
Так вот хотелось бы понять, какой из 2х способов более эффективный в плане расходования памяти и производительности. Сам склоняюсь ко второму способу, т.к. при build array, насколько я помню, происходит перестройка массива с возможным копирование при каждом добавлении нового элемента. А Вы что думаете?
Build array vs Queue
-
Chupakabra
- professional
- Сообщения: 360
- Зарегистрирован: 21 янв 2009, 10:50
- Награды: 1
- Версия LabVIEW: 2015
- Откуда: Москва
- Поблагодарили: 4 раза
- Контактная информация:
-
- professor
- Сообщения: 3406
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 176 раз
- Контактная информация:
Re: Build array vs Queue
Я думаю, что оба варианта довольно неуклюжи.
Во-первых, отображение 0-1-2 приводит к тому, что график постоянно дёргается, и история то накапливается то исчезает.
Более того, т.к. это разные массивы, то получается, что два plot-а на графиках то есть, то нет.
Что заставляет брать переменные массивы? Берите их постоянной длины, уже приятнее будет работать.
Ну и по поводу "экономии" памяти в случае с очередями, это больше похоже на самовнушение. В очереди элемент где-то хранится. И при извлечении всё равно идёт выделение памяти на сборный массив, так что где быстрее, сложно сказать. Проведите тесты на скорость - измерьте время исполнения одной итерации. Правда, надо минимизировать влияние генерации чисел.
Во-первых, отображение 0-1-2 приводит к тому, что график постоянно дёргается, и история то накапливается то исчезает.
Более того, т.к. это разные массивы, то получается, что два plot-а на графиках то есть, то нет.
Что заставляет брать переменные массивы? Берите их постоянной длины, уже приятнее будет работать.
Ну и по поводу "экономии" памяти в случае с очередями, это больше похоже на самовнушение. В очереди элемент где-то хранится. И при извлечении всё равно идёт выделение памяти на сборный массив, так что где быстрее, сложно сказать. Проведите тесты на скорость - измерьте время исполнения одной итерации. Правда, надо минимизировать влияние генерации чисел.
-
- doctor
- Сообщения: 2211
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 27 раз
Re: Build array vs Queue
При работе с очередью используется такт операционной системы. Т.е. очередь работает в потоке. Вместо того, чтобы перезаписать одну ячейку памяти, производится работа с потоком. Разница по затратам несколько порядков.
-
Chupakabra
- professional
- Сообщения: 360
- Зарегистрирован: 21 янв 2009, 10:50
- Награды: 1
- Версия LabVIEW: 2015
- Откуда: Москва
- Поблагодарили: 4 раза
- Контактная информация:
Re: Build array vs Queue
Иллюстрация, конечно, не законченная система сбора данных ). Вопрос касается больше не системы сбора данных, а эффективной визуализации этих данных. Графики так и должны дергаться, заказчику так нужно. Измерения должны отображаться на графике по мере поступления. Тут как не крути нужно динамически собирать массив кластеров массивов. И вопрос как более эффективно это делать.Artem.spb писал(а): ↑31 авг 2021, 18:56 Во-первых, отображение 0-1-2 приводит к тому, что график постоянно дёргается, и история то накапливается то исчезает.
Что заставляет брать переменные массивы? Берите их постоянной длины, уже приятнее будет работать.
Ну и по поводу "экономии" памяти в случае с очередями, это больше похоже на самовнушение. В очереди элемент где-то хранится. И при извлечении всё равно идёт выделение памяти на сборный массив, так что где быстрее, сложно сказать. Проведите тесты на скорость - измерьте время исполнения одной итерации. Правда, надо минимизировать влияние генерации чисел.
Переменные массивы приходят от железа, таков протокол обмена. Про выделении памяти при извлечении согласен, но это делается 1 раз, а при build array теоретически массив может копироваться столько раз, сколько вызывается build array, тут память и время расходуется при добавлении. Про тесты согласен, дадут объективную информацию, будет время проведу )
Последний раз редактировалось Chupakabra 01 сен 2021, 11:59, всего редактировалось 1 раз.
-
Chupakabra
- professional
- Сообщения: 360
- Зарегистрирован: 21 янв 2009, 10:50
- Награды: 1
- Версия LabVIEW: 2015
- Откуда: Москва
- Поблагодарили: 4 раза
- Контактная информация:
Re: Build array vs Queue
А вот тут не понял, очередь это хорошо или плохо в итоге?
Перезапись ячейки - это про массив? Если массивы имеют постоянный максимальный размер, то конечно можно эффективно перезаписывать начальные ячейки без изменения размера массивов и их более крупного объединения. Но когда массивы переменной длины, то "монолит" вероятно будет пересоздаваться при каждом изменении длины входящих в него массивов (так мне видится). При этом накладные расходы очереди покажутся детским лепетом.
-
- professor
- Сообщения: 3406
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 176 раз
- Контактная информация:
Re: Build array vs Queue
Посмотрите на Chart. Данные обновляются по мере поступления, но история при этом не выкидывается, это гораздо "приятнее".Chupakabra писал(а): ↑01 сен 2021, 11:42Графики так и должны дергаться, заказчику так нужно. Измерения должны отображаться на графике по мере поступления.
А почему именно кластер массивов, а не кластер двух точек (XY)? При получении очередного пакета его легко переформатировать и добавить к массивуТут как не крути нужно динамически собирать массив кластеров массивов.
А ещё интересный вопрос: а оно надо? Если техника справляется с задачей, то можно не заморачиваться с оптимизацией. В разумных пределах, конечно. Но в общем и целом надо сделать полную систему, и если она не "влезает" в бутылочное горлышко, то искать узкие (точнее, "широкие") места. Вполне возможно, что они будут вовсе не там, где вы сейчас пытаетесь оптимизировать.И вопрос как более эффективно это делать.
Вы по-прежнему уверены, что при помещении объекта в очередь вы никак не используете ни память, ни процессор?Переменные массивы приходят от железа, таков протокол обмена. Про выделении памяти при извлечении согласен, но это делается 1 раз, а при build array теоретически массив может копироваться столько раз, сколько вызывается build array, тут память и время расходуется при добавлении.
плохоА вот тут не понял, очередь это хорошо или плохо в итоге?
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
- 5 Ответы
- 270 Просмотры
-
Последнее сообщение AndreyDmitriev
-
- 2 Ответы
- 500 Просмотры
-
Последнее сообщение Artem.spb