I created a simple VI, which generates 800MB of data in an Array of DBL.
This sheet explaines how data are stored in the Memory - so if one DBL is stored in 8 Bytes, then an Array of DBL should Need
8 Bytes x n (Array size) + one integer (4bytes) indicating the Array size.
If I observe the Memory allocation of labview before and after clicking the button (Generation of Array), the Memory increases ~1600MB instead of 800MB. You can give a try!
Memory usage of LabVIEW:
Before generating Array: 216.384 k
After generating Array: 1.857.556
Can anybody give me an Explanation, why LabVIEW allocates the double of the required Memory?
Solved! Go to Solution.
Your control on the front panel which displays the data also needs a copy of the data. You could argue that the runtime array isn't needed once the VI terminates and therefore could be passed right to the control to be used instead of creating a copy but that is not how LabVIEW works. Imagine the situation where you have a subVI whose front panel is open. The output indicator that displays that array is supposed to show the data as it left the subVI to be passed to the caller, not some modified copy of that array that the caller later did modify, so controls always maintain their own data buffer copy if the panel on which they reside is not closed.
There are various other reasons why to do it in the way it is done now. For one most VIs are called multiple times during the lifetime of a program with similar array size requirements, and if you start your VI again it can reuse your array that it held a handle onto.
There is always a tradeoff to be made about strictly deallocating every memory buffer as soon as it is not used anymore or to hold on to it to be used again. The performance of LabVIEW is partly because it doesn't blindly deallocate buffers immediately but tries to reuse them for subsequent executions of the same diagram section whenever possible. Allocating and deallocating an array in a loop over and over again is a perfect performance killer.
If you find this disturbing you will have to move to a programming language where you can control every memory allocation explicitly. C or assembly comes to mind here The drawback here is that you not only CAN control every memory allocation but in fact MUST do so!
He doesn't have an array control on the front panel?
1024 X 1024 X 100 X 8 = 838.860.800 = 800 MB
Seems to be expected. Somewhere there is a copy though.
Avoiding that copy is the trick. I'd usually avoid DVR's, but for avoiding copies of large data they do the trick...
Also, in this particular situation, the copy seem to be needed for the combination of the event structure and shift register.
If you replace the initialize array with a reshape array on the "input" array, LV sees it's all the same array, and no copy will be needed. You do need to set the values to 0 though.
Deleting the array constant before the loop (initialize shift register) also avoids the copy...
But it's very likely you run into more problems like this, so it seem to solve the problem but doesn't really solve the problem...
a copy of data has been created. It is really not the solution of the Problem, but now I know what to take care about...
Perhaps it's the copy that's made for debugging. If you remove the "allow debugging" flag from the VI and then run the code, the memory does not increase (since the compiler removes the build-array code).
Forget about my reply, wiebe found the correct solution...