Прием потока данных

[Juri]

Написан тулкит приема потока данных (массив амплитуд) из сети ethernet 12800 байт в секунду в самом простом случае или тоже кол-во умноженное на 3 или на 4 если в сети несколько потоков от разных приборов. При этом происходит копирование одних и тех же байт 2 раза: 1 раз - из dll в тулкит, там они накапливаются до нужного объема, 2 раз - когда накопился нужный объем данных за 1 секунду, он посылается в очередь.
На скриншоте Read.vi забирает из очереди массив байт за одну секунду. Далее уже происходит парсинг и обработка.
На обычном компьютере все работает хорошо, но на одноплатнике уже приходится заниматься оптимизацией, т.к. на пределе загрузки цп, пакеты теряются. Если я не могу избавиться от копирования байт в первом случае, то хочу хотябы избавиться от копирования во второй раз. Никогда не пользовался палитрой Memory control. Сделана ли она именно для такой задачи? Дублирования данных не будет? Еще, ни разу не пользовался опцией Channel Writer. Она тоже для таких случаев?

[Juri]

Второй вопрос вдогонку. В примере есть 3 участка массива байт (в disabled структуре), который можно парсить одной vi, однако это сильно ухудшает производительность. Такой эффект возникает только когда код программы загружается из lvlibp. Первый график загрузки цп - когда используется суб vi. Второй график - когда код vi был продублирован три раза без использования суб vi. Игрался разными свойствами vi в меню Execution, но ничего не помогает. Впечатление, что свойство inline не работает если код загружен из lvlibp. Это лечится?

upd: Вероятно в LV21 этот косяк устранен

[Artem.spb]

Написан тулкит приема потока данных (массив амплитуд) из сети ethernet 12800 байт в секунду в самом простом случае или тоже кол-во умноженное на 3 или на 4 если в сети несколько потоков от разных приборов.

Из вашей картинки всё сразу очевидно, что даже хрустальный шар не нужен.
Написан кем?

При этом происходит копирование одних и тех же байт 2 раза:

Происходит зачем? Если авт ор вы, то избавьтесь от двойного копирования

1 раз - из dll в тулкит, там они накапливаются до нужного объема, 2 раз - когда накопился нужный объем данных за 1 секунду, он посылается в очередь.

Тут первая непонятнка с методом накопления, но главный вопрос: что мешает или сразу брать больше, или не копить, а отправлять дальше?

На скриншоте Read.vi забирает из очереди массив байт за одну секунду. Далее уже происходит парсинг и обработка.

И вот это не понятно. Вы копите данные с помощью очереди?

т.к. на пределе загрузки цп, пакеты теряются.

Работать на пределе загрузки вообще так себе затея

Дублирования данных не будет?

Это зависит от прямых рук программиста. Избежать ненужного копирования можно и без особых палитр

[Artem.spb]

Второй вопрос вдогонку. В примере есть 3 участка массива байт (в disabled структуре), который можно парсить одной vi,

Если Unflatten From String вы называете парсингом, то я бы призадумался над оптимизацией самого метода.
И если это некий массив, что мешает его разом конвертировать в последовательность чего-то там?
Если нет, то воспользуйтесь хотя бы String To Byte Array для начала

[Borjomy_1]

При такой "мощной" обработке и потоке данных возникают сильные сомнения, что проблема в парсинге и копировании данных. Используйте профилер, чтобы определить VI, которая грузит процессор. И уже с ней надо разбираться.

[Juri]

Я оптимизировал код, кое-где избавился от создания промежуточных кластеров данных, но самый главный вывод сделал в том, что если какая-то VI имеет priority "time critical priority (highest)" и при этом отправляет данные в очередь, то необходимо озаботиться, чтобы читающая из этой очереди VI тоже имела такой priority. иначе отправляющая VI будет тормозить, и не важно мало или много байт передается в очереди.