Производительность при использовании массивов

[maxim_MA]

Добрый день!
Давно заметил такую особенность, что при использовании 2D массивов или более падает производительность при выгрузке данных из цикла, особенно заметно при использовании больших массивов.

[Juri]

Когда идет борьба за производительность нельзя использовать операции добавления в массив. Массив надо инициализировать заранее до цикла, а внутри цикла юзать операции замены элемента массива

[maxim_MA]

Разве for loop не создает массив и потом производит операции по замене значений ? количеством итераций как раз и определяется размер массива на выходе и заранее выделяется память под эти данные или я не правильно понимаю?

[Artem.spb]

Если я не ошибся в расчётах, у вас там гигабайт банных. Что вас удивляет?

[dadreamer]

Разве for loop не создает массив и потом производит операции по замене значений ? количеством итераций как раз и определяется размер массива на выходе и заранее выделяется память под эти данные или я не правильно понимаю?

Вообще, да, массив в этом случае выделяется перед циклом. Только выделяется он изначально пустым (с нулевой длиной). А дальше его динамически расширяет на каждой итерации. Конечно, на это требуется время. Массивы в занимают непрерывную область памяти. Если текущий блок памяти нельзя расширить, не попав на следующие данные, то, очевидно, понадобится выделение нового блока и копирование. Для For Loop с подключенным терминалом итераций массив выделяется перед циклом и имеет заранее определённый размер. Причина различий в работе 1D/2D в другом. Также какое-то время тратится на обновление размера массива, для одномерного массива это одно поле Int32, для двухмерного два поля (см. How LabVIEW Stores Data in Memory, п. Arrays).

[maxim_MA]

Вообще, да, массив в этом случае выделяется перед циклом. Только выделяется он изначально пустым (с нулевой длиной). А дальше его динамически расширяет на каждой итерации. Конечно, на это требуется время. Массивы в занимают непрерывную область памяти. Если текущий блок памяти нельзя расширить, не попав на следующие данные, то, очевидно, понадобится выделение нового блока и копирование. Также какое-то время тратится на обновление размера массива, для одномерного массива это одно поле Int32, для двухмерного два поля (см. How LabVIEW Stores Data in Memory, п. Arrays).

Спасибо за развернутый ответ! буду учитывать в дальнейшем.

[alerm]

Массивы в занимают непрерывную область памяти.

Мне помнится, что массивы таким грешат во всех языках. Или я путаю?

[Borjomy_1]

Заявление о создании пустого массива и добавления в него - сомнительное. По моему опыту если Labview имеет данные о размере массива (количество циклов For и фиксированный размер элемента), то необходимый объем выделяется СРАЗУ.
Но! В вашем случае используется опция "concatinate" именно она и является причиной торможения. Попробуйте использовать автоиндексацию, а потом ReShape для приведения к нужной размерности

[Artem.spb]

Вообще, да, массив в этом случае выделяется перед циклом. Только выделяется он изначально пустым (с нулевой длиной). А дальше его динамически расширяет на каждой итерации. Конечно, на это требуется время.

В очередной раз озадачился, почему в древних талмудах говорилось, что использовать индексацию в while loop это атата, а вот в for - самое то? Раньше было не так, массив выделялся сразу весь?
И до сих пор while по умолчанию индексация выключена, а for включена.

[Artem.spb]

Массивы в занимают непрерывную область памяти.

Мне помнится, что массивы таким грешат во всех языках. Или я путаю?

Было бы странно фрагментировать области памяти

[Artem.spb]

Заявление о создании пустого массива и добавления в него - сомнительное. По моему опыту если Labview имеет данные о размере массива (количество циклов For и фиксированный размер элемента), то необходимый объем выделяется СРАЗУ.

По моему опыту в последних версиях разницы как раз нет. Я не смог получить ускорение в генераторах при использовании for/while

upd.
Скорость отличается в 4 раза. Мир перевернулся обратно

[alerm]

Было бы странно фрагментировать области памяти

А кластер разве делает не так? Блин, я реально уже не помню, может мне это почудилось

[Artem.spb]

Было бы странно фрагментировать области памяти

А кластер разве делает не так? Блин, я реально уже не помню, может мне это почудилось

Не совсем так.
Все простые элементы лежат пачкой, а составные (массивы всякие) в кластере лежат ссылкой, а ссылка уже куда попало указывает.
Так что для массива утверждение о фрагментации верное, а для всего остального - нет

[Artem.spb]

Добавил ещё один тип for
В общем, если размер известен, заранее выделять не обязательно

[dadreamer]

Массивы в занимают непрерывную область памяти.

Мне помнится, что массивы таким грешат во всех языках. Или я путаю?

Кстати, хорошо подмечено, зря я акцент на поставил. В большинстве языков, по крайней мере в C/C++, под массив выделяется непрерывная область в виртуальной памяти. В физической это может вполне соответствовать разным областям, но программиста обычно это не должно беспокоить. Хотя в некоторых языках можно выделять и НЕ-непрерывный массив, скажем, в Python или Swift. Но я там не эксперт, так что не скажу, обычное ли это явление или надо как-то специально это делать.