LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

In-Place Element and Buffer Allocations

Solved!
Go to solution

I have an application that will have several large 2D arrays where I'll need to periodcially update certain rows in each array.  To minimize the copies that LabView will make in passing these giant arrays around, and in doing my array operations on them, I'm looking at using the In-Place Element structure.

 

An small example is attached in the picture.  Here, I preallocate a 2D array (small in this example, larger in application), create a data value reference to the array, and then pass it to the IPE.  I replace a row inside the IPE and pass it back out the other end.  Using the tool to highlight buffer allocations though suggests that I'm not really operating on anything 'in-place'.

 

Some questions...

 

1. There's a dot on the Data Value Reference VI...what buffer is being created there exactly? 

2. There's a dot on the left side of the IPE where I read the reference...suggesting that the IPE is taking my reference and creating another array...exactly what I'm trying to avoid.

3. The above tells me that just because you shove stuff in an IPE doesn't mean you actually do that stuff "in-place". 

 

What's the best way to do this?  It would seem that I'd have to wire the 2D array itself to the IPE and use the index/replace option.  Downside...I'd have to put this in a loop and replace one element at a time, rather than an entire row (or several rows) at a time. And, I'd have to create some large data structures to pass my large 2D arrays through sub-VI's.

 

 

 

 

 

0 Kudos
Message 1 of 7
(3,558 Views)
Solution
Accepted by topic author cochenob

Read through the discussion at http://forums.ni.com/t5/LabVIEW/LabVIEW-2015-Buffer-Allocation-Bug/td-p/3300392

 

This may help you make sense of what to do.

 

mcduff

Message 2 of 7
(3,544 Views)

Which of the options do you have checked in the Show Buffer Allocations window? If you check off everything, you'll see buffer allocations for everything, such as for the DVR itself (which is a minimal amount of memory, but is still an additional allocation).

0 Kudos
Message 3 of 7
(3,531 Views)

Thanks mcduff.  Interesting!  Well...disappointing, but interesting.


I notice that if I wire a DVR of an array to an IPE...and don't do anything inside the IPE except run the array straight over to the other side of the IPE...even then a buffer allocation is shown.  As suggested in the link, the complier apparently isn't smart enough to look inside the IPE and see that nothing is happening, so it makes an allocation because it doesn't know any better. 

 

That said...what good is it to have an option to read/write a DVR in an IPE if the IPE is always going to create a copy?  Seems to defeat the purpose.  Unless this is one of those instances where it's just showing the potential for additional memory allocation.  Either way, it would be helpful to understand what memory gets allocated when using DVRs, and goes back to my first question, which is "why does it show there's an array being created when I first create the DVR?".

 

 

0 Kudos
Message 4 of 7
(3,530 Views)

nathand-

 

Just 'array', unfortunately.  Looking to understand exactly what array is being allocated when I create the DVR.

 

 

0 Kudos
Message 5 of 7
(3,529 Views)

Look at the inline picture posted here.

 

1. There's a dot on the Data Value Reference VI...what buffer is being created there exactly? 

Do not use constants, change your dimensions to controls. The compiler does not know whether it will need the constant array later so a copy is made.

2. There's a dot on the left side of the IPE where I read the reference...suggesting that the IPE is taking my reference and creating another array...exactly what I'm trying to avoid.

This is not really a buffer allocation, do not believe this dot, a dot on the right side of the IPE DOES indicate a buffer allocation.

3. The above tells me that just because you shove stuff in an IPE doesn't mean you actually do that stuff "in-place". 

If wired correctly, there is some voodoo to this, there is no allocation. (See the earlier post I linked.)

 

mcduff

 

Snap1.png

0 Kudos
Message 6 of 7
(3,504 Views)

I'll chime in with some observations:

 

Firstly, the allocation of the DVR itself (when converting the Array to a DVR) is correct.  A new pointer needs to be allocated for this.  The allocation is therefore 4 bytes in 32-bit LV and 8 bytes in 64-bit LV.  Not really something to worry about.

 

The buffer ellocation on the left-hand side of the IPE is the compiler simply playing safe.  It COULD be that you feed in an invalid DVR reference in which case the IPE will then have to actually instantiate an empty array within the structure.  Only then does this buffer allocation occur.  The compiler is not smart enough to look upstream a little and see that the DVR is certainly not invalid.  This allocation is not real (in the code shown at least).

 

The operations will be done in-place if they can be done in-place.  Using the IPE there are still plenty of cases where there is no option but to allocate memory (Trying to read an index of an array which doesn't exist causes allocations, trying to access an invalid DVR causes allocations and so on).

 

At the end of the day, benchmarking is important.

 

Shane

Message 7 of 7
(3,462 Views)