I have a program which generates and display rather large 2D arrays (20+Mb). These arrays are bundled into a cluster together with other variables, which is defined outside a Case-Loop in order to make it available to other cases. See attached vi with an example of this operation. To check if this causes duplication of data I use the "Show Buffer Allocations" and according to it, it doesn't allocate a new buffer in the bundle-operation. When I run my program in slow-mo and watch the Mem Usage in Windows Task Manager it DOES create a buffer (In the example mem-usage increases 24Mb when it bundles the data). This is rather disappointing since I hoped a bundling operation only stored a pointer to the data, and it is obviously a bug in LV 8.6.1 since it doesn't report this alloc in "Show Buffer Allocations".
Can anyone comment on this finding?
If its unavoidable to not buffer data in a bundle, what is the best option to store large arrays and at the same time make it available to other parts of the program? Do I need to "litter" the block-diagram with Local variables?
Regarding passing the array to aSubVI, it does report a buffer alloc. Is it possible to avoid this buffer in any way, like in C when you pass a pointer of the data.
Solved! Go to Solution.
I think what you're seeing here is the difference between allocating a buffer, and resizing one. There's already a buffer allocated for the array in the cluster, but it needs to be resized in order to copy the data generated in the for loop. I'm not sure why LabVIEW decides it needs to copy all the data in this case, but you can avoid it by using an in-place element structure (found in the application control palette under memory control) as shown below. Local variables create additional data copies, so that's definitely not the right solution. As for subVIs, it depends on the code inside the subVI. If the subVI can act in-place, there is no data copy. There are many, many posts here about inplaceness, and what it means for a subVI to act in-place.
Re:inplaceness and sub-VIs... See the "Clear as Mud" thread found here. Reply #12 is by Greg Mckaskle is a Senior Architect (or something like that) for LV R&D and he "lifted the hood and let us take a look" in that thread. Allocate some time to rad that thread. It ain't light reading.
Nathan: You're probably right that its a resize operation that causes the extra memory alloc, and as such its not defined as a buffer alloc in LV. If I initialize the array with the right size, (which isn't practical in orig application), I probably wont get this alloc at the bundle op (the mem use will probably be the same though). I'll check it out when I get back to work on Monday. The inplaceness is something I need to look into because when working with large data in LV it is extremely important to reduce the amount of data copying. I guess thats the price you pay for not having to deal with memory management.
Ben: I'll look into the linked post on Monday, in my working time :-). Mem management is indeed tricky in LV because a lot is hidden and while its a lot of good info on the forum about it, it is sometimes difficult to understand whats going on, so it would be nice if NI could provide a good article about these things (I know there are at least one article about it, but I dont think it addresses all these issues)
Thanks for the info guys!