Build array vs Queue

[Chupakabra]

Есть система сбора данных, которая производит несколько измерений, накапливает их и попутно отображает на 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, насколько я помню, происходит перестройка массива с возможным копирование при каждом добавлении нового элемента. А Вы что думаете?

[Artem.spb]

Я думаю, что оба варианта довольно неуклюжи.
Во-первых, отображение 0-1-2 приводит к тому, что график постоянно дёргается, и история то накапливается то исчезает.
Более того, т.к. это разные массивы, то получается, что два plot-а на графиках то есть, то нет.

Что заставляет брать переменные массивы? Берите их постоянной длины, уже приятнее будет работать.

Ну и по поводу "экономии" памяти в случае с очередями, это больше похоже на самовнушение. В очереди элемент где-то хранится. И при извлечении всё равно идёт выделение памяти на сборный массив, так что где быстрее, сложно сказать. Проведите тесты на скорость - измерьте время исполнения одной итерации. Правда, надо минимизировать влияние генерации чисел.

[Borjomy_1]

При работе с очередью используется такт операционной системы. Т.е. очередь работает в потоке. Вместо того, чтобы перезаписать одну ячейку памяти, производится работа с потоком. Разница по затратам несколько порядков.

[Chupakabra]

Во-первых, отображение 0-1-2 приводит к тому, что график постоянно дёргается, и история то накапливается то исчезает.

Что заставляет брать переменные массивы? Берите их постоянной длины, уже приятнее будет работать.

Ну и по поводу "экономии" памяти в случае с очередями, это больше похоже на самовнушение. В очереди элемент где-то хранится. И при извлечении всё равно идёт выделение памяти на сборный массив, так что где быстрее, сложно сказать. Проведите тесты на скорость - измерьте время исполнения одной итерации. Правда, надо минимизировать влияние генерации чисел.

Иллюстрация, конечно, не законченная система сбора данных ). Вопрос касается больше не системы сбора данных, а эффективной визуализации этих данных. Графики так и должны дергаться, заказчику так нужно. Измерения должны отображаться на графике по мере поступления. Тут как не крути нужно динамически собирать массив кластеров массивов. И вопрос как более эффективно это делать.
Переменные массивы приходят от железа, таков протокол обмена. Про выделении памяти при извлечении согласен, но это делается 1 раз, а при build array теоретически массив может копироваться столько раз, сколько вызывается build array, тут память и время расходуется при добавлении. Про тесты согласен, дадут объективную информацию, будет время проведу )

[Chupakabra]

При работе с очередью используется такт операционной системы. Т.е. очередь работает в потоке. Вместо того, чтобы перезаписать одну ячейку памяти, производится работа с потоком. Разница по затратам несколько порядков.

А вот тут не понял, очередь это хорошо или плохо в итоге?
Перезапись ячейки - это про массив? Если массивы имеют постоянный максимальный размер, то конечно можно эффективно перезаписывать начальные ячейки без изменения размера массивов и их более крупного объединения. Но когда массивы переменной длины, то "монолит" вероятно будет пересоздаваться при каждом изменении длины входящих в него массивов (так мне видится). При этом накладные расходы очереди покажутся детским лепетом.

[Artem.spb]

Графики так и должны дергаться, заказчику так нужно. Измерения должны отображаться на графике по мере поступления.

Посмотрите на Chart. Данные обновляются по мере поступления, но история при этом не выкидывается, это гораздо "приятнее".

Тут как не крути нужно динамически собирать массив кластеров массивов.

А почему именно кластер массивов, а не кластер двух точек (XY)? При получении очередного пакета его легко переформатировать и добавить к массиву

И вопрос как более эффективно это делать.

А ещё интересный вопрос: а оно надо? Если техника справляется с задачей, то можно не заморачиваться с оптимизацией. В разумных пределах, конечно. Но в общем и целом надо сделать полную систему, и если она не "влезает" в бутылочное горлышко, то искать узкие (точнее, "широкие") места. Вполне возможно, что они будут вовсе не там, где вы сейчас пытаетесь оптимизировать.

Переменные массивы приходят от железа, таков протокол обмена. Про выделении памяти при извлечении согласен, но это делается 1 раз, а при build array теоретически массив может копироваться столько раз, сколько вызывается build array, тут память и время расходуется при добавлении.

Вы по-прежнему уверены, что при помещении объекта в очередь вы никак не используете ни память, ни процессор?

А вот тут не понял, очередь это хорошо или плохо в итоге?

плохо