Showing results for 
Search instead for 
Did you mean: 

Replace Array Subset / Insert Into Array functions are VERY slow with unknown element

Go to solution

I've put up an array benchmark for some operations I'm interested in and its results confusing me.

The problem is when I use Replace Array Subset / Insert Into Array functions with some user-defined element they work VERY slow compared to other functions tested. However, if I use them with a (non-zero) constant element instead they perform just as fast.

I'm running it in LabVIEW 2018 SP1. Can somebody explain this?

0 Kudos
Message 1 of 10

Hi Evgen,


once you remove that additional multiply operation for your test scenarios "Replace" and "Insert" the results are in the same magnitude for all test scenarios…

After reviewing your VI I changed the "Replace" scenario to use shift registers: now it's as fast as the other scenarios.

The "Insert" case stays slow as the Insert operation requires a lot of memory handling, which is slow for arrays of 100M elements!

Other cases, like those "Delete" tests become slower when using shift registers.


IMHO the whole test is senseless as you don't test the speed of the array operation alone, but the speed of memory handling routines in combination with compiler optimizations for specific scenarios…

Best regards,
CLAD expired, using LV2011SP1 + LV2017 (+LV2019 sometimes) on Win7+cRIO
Kudos are welcome Smiley Wink

Message 2 of 10

Hi, thanks for a such a fast reply.

Well, the point of multiplication is to get results for the same number of iterations for each test (see I divided it before, otherwise it would just take forever to execute).

Here is what I get:


And as I said, if I replace Numeric with the same constant (and set divisor to 1) it works lightning-fast. So it seems like LabVIEW can pre-allocate an array once with a constant, but for some reason it can't with an arbitrary value...


EDIT: Yeah, shift register works well for Replace, thanks. However, I still confused why it's not with a tunnel...

0 Kudos
Message 3 of 10

Hi Evgen,


@EvgenKo423 wrote:

EDIT: Yeah, shift register works well for Replace, thanks. However, I still confused why it's not with a tunnel...

Because with a shift register ReplaceArraySubset can work "in place", while with tunnels in each iteration a new memory copy needs to be created.

Again: you are testing memory handling mixed with compiler optimizations!

Best regards,
CLAD expired, using LV2011SP1 + LV2017 (+LV2019 sometimes) on Win7+cRIO
Kudos are welcome Smiley Wink

Message 4 of 10

The Search 1D Array might considered a no-op (as the output isn't used), and simply removed by the compiler.


Please simply insert images, not URLs to weird sites. probably removes that image long before this post stops existing.

0 Kudos
Message 5 of 10
Accepted by EvgenKo423

Replace and Insert are probably slow because you read from a local in the loop. That's not a test of Replace and Insert, but (also, probably mostly,) of reading the local.

Message 6 of 10

Thanks for your input, it affected the results indeed.


I've sent search result into an indicator outside a loop and it made it close to 2 times slower. I moved access to local variable outside a loop and it gave about 25% to Replace time (with shift registers).

0 Kudos
Message 7 of 10

@wiebe, you actually was completely right!

I did try moving local outside an Insert loop, but I didn't see any difference because of shift register kept increasing an array. After I switched shift register to tunnel the speed got back to expected.

Thank you!


EDIT: Furthermore, if I simply copy the whole array before the Insert loop it runs about 35% faster. I guess it has something to do with extra space allocation for future array growth.

0 Kudos
Message 8 of 10

LabVIEW performance is affected by too many things for me to explain in a single post but I have collected this "Tag Cloud for LabVIEW Performance" discussions.



Memory allocation

Optimizing code

constant folding

buffer allocations


Are just a short list of things to consider.


Tools >>> Profile >>> Show Buffer allocations


Is a nice tool that will let you SEE more about where the memory reallocation comes into play.


And then when you think you got it figured, Look at Christian Altenbach's posts and try to figure out how to write code that is faster than his. While you may not beat his code, the attempt will make you a better developer.


I did beat his code ONE time but it was a corner case but that was many years ago/



Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 9 of 10

Also note that the compiler changes.


Back in LV4, adding a scalar to an array was faster than adding an array to a scalar...


A big performance revolution was made by using the LLVM compiler. At the moment, requested functions are not added to LabVIEW, because a VI(M) can do it just as fast.


The fastest way to search all matches in an array used to be to put Search 1D Array in a loop. Nowadays it is faster to simply put a Equal? in a for loop.


Preallocating arrays used to be the (only) way to create arrays in loops. Now autoindexing got so good, it's almost always faster (and less code).

Message 10 of 10