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

[EvgenKo423]

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?

[GerdW]

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…

[EvgenKo423]

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...

[GerdW]

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!

[wiebe@CARYA]

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. Postimg.cc probably removes that image long before this post stops existing.

[wiebe@CARYA · Accepted solution]

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.

[EvgenKo423]

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).

[EvgenKo423]

@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.

[Ben]

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.

Inplaceness

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.

Spoiler

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

Ben

[wiebe@CARYA]

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).