LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Efficient way to build arrays

Hi everyone,

 

My question is: Build Array Faster. HOW?

 

Solution:

Use new coming value at new index. Means, Build your array as new value comes at lower side of build. Really fast way to build array.

 

Refer sneppit.... Try it by yourself....


Best Regards,
DCKAN

"We make a Living by what we get. We make a Life by what we give."
0 Kudos
Message 1 of 18
(5,077 Views)

If you know the ultimate array size ahead of time, it reall pays to preallocate the array size.  Using a for loop's auto index function works well.

 

The Build array and shift register method really slows everything down, since the array size is changing every iteration.  This is because the computer has to reallocate a new space in memory for the whole array every single iteration.

 

If you really want to speed up the array build, then you'll want to preallocate an array with a bunch of zeros and replace the elements as you go. 

 

Probably not a big deal for small arrays, but the time savings is huge when the arrays are huge.

0 Kudos
Message 2 of 18
(5,049 Views)

So it looks like it's 125x faster to add a new element at the end of the array. I don't know how the Build Array works in the backround, but I assume this is because it requires some shifting when you add an element at the beginning?

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 3 of 18
(5,045 Views)

Hi James,

 

So it looks like it's 125x faster to add a new element a t the end of the array

LabVIEW uses some "smart" way when adding new elements at the end: it allocates a bigger buffer then actually needed. So it has to allocate new buffers more seldomly. When prepending new elements it is not as smart so needs more buffer allocations…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 4 of 18
(5,029 Views)

Yeah I've heard it is actually faster to perform a reverse 1D array, add at the end, reverse 1D array again, rather than add at the front.  I personally haven't tested this, and if this were the case I'm not sure why the compiler wouldn't just do it this way behind the scenes.

0 Kudos
Message 5 of 18
(5,004 Views)

@Hooovahh wrote:

Yeah I've heard it is actually faster to perform a reverse 1D array, add at the end, reverse 1D array again, rather than add at the front.  I personally haven't tested this, and if this were the case I'm not sure why the compiler wouldn't just do it this way behind the scenes.


 Gosh, this whole time I've tried so hard to stay away from the Reverse 1D function because I assumed it had more overhead than just creating the array the right way from the start. I guess I'm reminded again what assuming does.

 

Edit: It looks like this is not the case... I get 125x iterations with the above code, but with the Reverse 1D Array nodes, it slows down considerably to where the first method is anywhere from 150x to 280x faster.

Example_VI_BD.png

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 6 of 18
(4,993 Views)

@James.M wrote:

@Hooovahh wrote:

Yeah I've heard it is actually faster to perform a reverse 1D array, add at the end, reverse 1D array again, rather than add at the front.  I personally haven't tested this, and if this were the case I'm not sure why the compiler wouldn't just do it this way behind the scenes.


 Gosh, this whole time I've tried so hard to stay away from the Reverse 1D function because I assumed it had more overhead than just creating the array the right way from the start. I guess I'm reminded again what assuming does.


The Reverse 1D Array actually just creates a new pointer to the array with a step set to -1.  The array is not reallocated just from a Reverse 1D Array.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 7 of 18
(4,975 Views)

@crossrulz wrote:

he array is not reallocated just from a Reverse 1D Array.


That's what I've heard, same with Transpose 2D array, this is apparently very easy to do by changing the pointer values.

 

That being said you time checking code might be a bit flawed.  Reading and writing to front panel controls can mess with timing code, so it is suggested to only read control terminal values before the timer starts, and to only write to front panel terminals after the timer stops.  That being said if you aren't constantly writing or reading terminals in a loop the amount of jitter this adds is pretty minimal.

 

Edit: Whatever, your code is fine.

0 Kudos
Message 8 of 18
(4,960 Views)

Hi,

 

This may be all about "shifting" of indices of all elements of an array in second case. While in first case, all LabVIEW needs to do is, "add next index"..

 

Even if we know array size very before we build, instead of pre allocating space for array, I would prefer this function if only build is required.

 

After all, time matters...

 

 

 


Best Regards,
DCKAN

"We make a Living by what we get. We make a Life by what we give."
0 Kudos
Message 9 of 18
(4,953 Views)

@crossrulz wrote:
The Reverse 1D Array actually just creates a new pointer to the array with a step set to -1.  The array is not reallocated just from a Reverse 1D Array.

Can you explain the timing difference I'm seeing above in my edited reply?

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 10 of 18
(4,940 Views)