Data Value Reference allocates twice the amount of RAM

[BowenM]

I'm working on a project that is going to need to have some large circular arrays stored in memory.  So, I was doing some stress testing... and noticed some behavior that I can't explain.  See attached images.

Both are initialized as i16 (I tripple checked it because I was confused).  I'm not asking how to fix it, just curious as to why the compiler allocates 2x the memory for a data value reference.  Someone learn me!

[crossrulz]

What if you create the DVR from the initialized array instead of the empty array?  Does the issue go away?

My thought here is that you are allocating 2 arrays: the initialized array and the new array being stored in the DVR.  By creating the DVR from the initialized array, you should be avoiding the extra copy.

[BowenM]

Oddly enough, it did go away if I initialized the array and then turned it in to a DVR.  So what you are thinking the compiler is doing is:

1. Initialize empty array in memory (Array1). Pass it around via DVR.

2. In place element structure, initialize new array in memory (Array2).

3. Array2 takes up memory. Set Array1 == Array2.  Array exists twice in memory.

4. Exit in place element structure.  Array1 is still == Array2, but Array2 memory is never freed up by compiler...?

Doesn't that kind of defeat the purpose of DVR?  Or is it one of those cases of "Well, as far as Windows is concerned, LabVIEW has now taken up that mount of RAM.  As far as LabVIEW is concerned, that memory is free for it to use elsewhere.

I guess the test would be... Initialize Array1. Initialize Array2. Wait a few seconds, initialize Array3 after in place element is closed.  Check to see if it takes up 3x the memory or only 2x like it did before.

[Oligarlicky]

Put a wait after you deallocate your Delete DVR you'll see the memory step down. It's one allocation for the initialize array (a memory space full of zeros) and one allocation for the DVR (which might change down the road). One hint that the compiler might do this is the fact that the wire from the DVR read doesn't make it all the way back to the write. That implies it's not an in place operation.

[Intaris]

Try using a "Swap Values" primitive within the In-Place Element structure instead of throwing the old data away and writing the new data to the DVR.

I've done this in the past and it can work wonders sometimes.