Why does the "Replace Array Subset" double the used memory?

[atilla]

Hi all,

See the attached images.

The first vi with an array of doubles uses ~8 MB as expected. When I add a "Replace Array Subset" an additional buffer is created at the shift register, the used memory is doubled to 16 MB. Is there a way to avoid this? My intention is to replace existing array space, I don't see the need for an additional copy in this case ..

The In Place Structure doesn't work here either...

This is a cross post: http://forums.ni.com/ni/board/message?boar...=125662#M301485

Thanks in advance

atilla

[Tomi Maila]

LabVIEW reserves always a new buffer for a shift register. In the first case however, the shift register is not used and therefore it's not allocated either. You can try to NI R&D team about suboptimal buffer reuse optimization.

[george seifert]

That's odd. I'm doing something similar (2D array), initializing an array before the loop, sending it to a shift register and replacing array data within the loop. I'm not getting an allocation dot at the shift register. I'm using LV 8.5.

George

[atilla]

QUOTE(george seifert @ Feb 14 2008, 02:45 PM)

That's odd. I'm doing something similar (2D array), initializing an array before the loop, sending it to a shift register and replacing array data within the loop. I'm not getting an allocation dot at the shift register. I'm using LV 8.5.

George

Hi George,

Odd indeed, this code is 8.5 as well. What does your code look like?

atilla

[ragglefrock]

QUOTE(atilla @ Feb 14 2008, 08:29 AM)

Hi George,

Odd indeed, this code is 8.5 as well. What does your code look like?

atilla

I don't think anyone's quite hit on the right answer yet. The reason you're seeing the buffer allocation dot on the shift register for the data that's being modified is that LabVIEW has to allocate a buffer to copy the constant data into data that can be modified.

You are initializing the 8MB array using constant values. The output of that Initialize Array function is always going to be the same, so LabVIEW constant-folds it out by putting the actual array in the executable code during compile-time. The result is exactly the same as if you had placed an array constant with a million elements in it on the block diagram.

So LabVIEW sees that you are going to modify this array with the replace array subset in the loop. LabVIEW won't let you modify the constant copy built into the executable code itself, because that would change the VI's compiled code itself. You wouldn't be able to run the program again and get the same results! So LabVIEW allocates a mutable buffer and copies the constant data in.

Shift Registers don't always allocate a buffer for their use. They can certainly reuse buffers where appropriate. Here, however, it is not appropriate to modify constant data.

To get around the copy, you need to trick LabVIEW into not constant-folding the 8MB constant value onto the diagram, so that the array actually gets allocated at run-time instead of compile-time as a constant. You can do this by changing either the array size parameter or the array element value parameter to a control with the proper default value set. Then LabVIEW can't 100% know that the initialized array will be the same every time, so it won't constant fold. The result will be 1 8MB array instead of 2.

[george seifert]

QUOTE(atilla @ Feb 14 2008, 08:29 AM)

Odd indeed, this code is 8.5 as well. What does your code look like?

Here's my code. There will be some subvis missing, but you don't need them to see what's going on with the shift register.

George

http://lavag.org/old_files/post-2786-1203005679.vi'>Download File:post-2786-1203005679.vi

[atilla]

QUOTE(george seifert @ Feb 14 2008, 05:15 PM)

Here's my code. There will be some subvis missing, but you don't need them to see what's going on with the shift register.

George

Download File:post-2786-1203005679.vi

Hello George,

Thanks for posting your code. I stripped it down and found something strange:

The first vi does not have the additional buffer. In the second I only changed the control to a constant, the buffer shows up... Looks like a bug?

atilla

[TobyD]

QUOTE(atilla @ Feb 14 2008, 08:58 AM)

The first vi does not have the additional buffer. In the second I only changed the control to a constant, the buffer shows up... Looks like a bug?

I don't think this is a bug. Take a look at ragglefrock's post above. It gives an excellent explanation of why this happens and it has helped me to grasp the concept of constant folding for the first time. :thumbup:

[Aristos Queue]

A) Tomi isn't quite correct in his reply. A shift register does not always get a buffer allocation. It starts off with a buffer allocation, but we try to consolidate these down.

B) Your instincts are correct that we ought to be able to consolidate in this situation. EXCEPT... your inputs to the Initialize Array function are all constants. That means that Initialize Array has been constant folded and the buffer is there in your VI's save image. To avoid stepping on the value of the constant when we run the loop, the shift register makes its own copy. If you change any of those initial constants into controls, the buffer copy will go away.

[atilla]

QUOTE(Aristos Queue @ Feb 14 2008, 06:23 PM)

A) Tomi isn't quite correct in his reply. A shift register does not always get a buffer allocation. It starts off with a buffer allocation, but we try to consolidate these down.

B) Your instincts are correct that we ought to be able to consolidate in this situation. EXCEPT... your inputs to the Initialize Array function are all constants. That means that Initialize Array has been constant folded and the buffer is there in your VI's save image. To avoid stepping on the value of the constant when we run the loop, the shift register makes its own copy. If you change any of those initial constants into controls, the buffer copy will go away.

Okay, that makes sense, thanks for the explanation Aristos!

atilla

[jcabrer]

I would be interested in hearing any insights into why, if the array is preallocated and we are only replacing inside the loop, does the memory usage increase as the loop progresses. I ran accross this topic while experiencing this same issue with a preallocated array (2500x2500x2). The array begins with all elements set to zero, but as the loop (while or for, makes no diff) runs, memory use starts going up until all memory runs out.

I've also tried the In Place structure, but so far there seems to be no added benefit.

[Ton Plomp]

QUOTE (jcabrer @ Mar 27 2008, 04:53 PM)

I would be interested in hearing any insights into why, if the array is preallocated and we are only replacing inside the loop, does the memory usage increase as the loop progresses. I ran accross this topic while experiencing this same issue with a preallocated array (2500x2500x2). The array begins with all elements set to zero, but as the loop (while or for, makes no diff) runs, memory use starts going up until all memory runs out.

I've also tried the In Place structure, but so far there seems to be no added benefit.

Hi jcaber,

could you add your code (or a screenshot)?

Ton

[Rolf Kalbermatter]

QUOTE (jcabrer @ Mar 27 2008, 10:53 AM)

I would be interested in hearing any insights into why, if the array is preallocated and we are only replacing inside the loop, does the memory usage increase as the loop progresses. I ran accross this topic while experiencing this same issue with a preallocated array (2500x2500x2). The array begins with all elements set to zero, but as the loop (while or for, makes no diff) runs, memory use starts going up until all memory runs out.

I've also tried the In Place structure, but so far there seems to be no added benefit.

There is something fishy about this, and considering that I use LabVIEW quite a lot in such scenarios without seeing this I would have a hunch that it is something you are doing that causes this, and not a bug in LabVIEW.

Show your code and we can look at it.

Rolf Kalbermatter