LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is Delete From Array function optimized while deleting from the front or end of an array.

Solved!
Go to solution

Late update. Thank nathand, Bob, and altenbach, the discussion has gradually lift the clouds in my mind. Now I realize that I have misunderstood the problem i confronted and the deed that i was concerning could converge to one quite simple question.

As I was dealing with large data, I was worrying about the Delete From Array function is creating a new large subarray apart from the input array in the memory and stuff it.

So the simple question is, when there is no branching of the input array, whether Delete From Array creates a new subarray copy in memory or just reuse that part of memory of the input array (i.e. in-place). And is the Array Subset works the same way?

I think the answer is clear, the in-place one and Yes. But could you guys confirm me if you please.

Still, the benchmark result is interesting.

demo.PNG

0 Kudos
Message 11 of 13
(1,173 Views)
Solution
Accepted by topic author hlcfreelook

The LabVIEW compiler often has amazing tricks up his sleeves, and some operations recognize if one of the outputs is not connected and skip the unneeded calculations (while some don't). Exploring these things is difficult. You might want to repeat Bob's code while disconnecting some of the outputs to see if it makes a difference. Somebody from NI could shed more light.

 

I think the multiplication by 2 is definitely in-place but you also might want to compare with "Scale by power of two", which is a simpler operation in binary (A simple bit shift for integers and some trivial bit manpipulations for floating point). Still, even a plain multplication is never the limiting factor.

 

Todays computers are very fast and unless you experience performance problems (or are trying to win a coding competition :D) it does not really matter. Does your code perform suficiently well?

 

For some related discussion watch our NI Weeek 2016 presentation.

0 Kudos
Message 12 of 13
(1,160 Views)

@hlcfreelook wrote:

Thank you for replying.

Following your thinking I inferred that deleting n elements from the beginning of an array could also be optimized, by just reducing the array size by n and move the array pointer along n positions.

I found that the buffer allocations is no difference even for Delete From Array with and without the index input wired (see attached figure). Well, a buffer allocation doesn't neccessary mean data copying. Is it?


Technically that is not true. A memory pointer is not something you can just arbitrarily offset at will. In order to free that memory at some point again you have to maintain the original pointer somewhere, otherwise the memory manager will really start to bark at you if you pass it an arbitrary pointer that isn't the original pointer that it returned but instead pointing somewhere into the memory area that was originally allocated.

 

BUT!!!! LabVIEW does know something they call subarray. Please note that the LabVIEW nomenclature is just opposite to what you use yourself here. It is an internal datatype that is not a new array allocation but instead a management structure that maintains a pointer to the original array along with an offset, size and flags structure. With the offset they can manage for instance deletion of elements from the start of the array by simply creating a subarray with the according offset. Flags can be used to store states such as a 2D array whose dimensions have been transposed.

But as soon as you get into >= 2D arrays there are obviously umptien combinations to the problem of offset, size, transpose and what else, so LabVIEW does not support subarrays for every thinkable combination of these. Also deleting from the start of a 2D or higher array is only easily manageable in this way if you delete from the outer dimension, otherwise you would end up with a sparse array whose data parts are not anymore contigous and managing that array gets more complicated than simply recreating it and copying the relevant data.

 

And please note that a subarray creation is technically an allocation too! It's not allocating a copy of the super mega array but a structure to maintain the management data for this array. So when you do a "show buffer allocations" it will simply have a dot too! Technically it does allocate a buffer for the subarray management data.

 

Last but not least, while many LabVIEW built in nodes do operate on subarrays, not all of them can for every possible combination of offset, size and flags. Each of these nodes does a check for a subarray type and the parameters of the subarray and if it determines that it can not support the specific subarray it will simply trigger the recreation of the real array in order to proceed correctly. So there is a chance that for some functions downstream the subarray would be converted into a real array anyhow. This also applies across subVI borders.

 

Rolf Kalbermatter
My Blog
Message 13 of 13
(1,126 Views)