This occurs in LabVIEW 2015 SP1 32bit running on 64bit Win 7; it does not seem to occur in LabVIEW 2014.
Look at the screen shot, the subVI is a simple in and out with no operations.
In the IPE a buffer copy occurs (red circle), but not in the other case. Does anyone have an idea why this is the case? I would like to use the IPE structure to select a subset of the data to operate on, so the other case does not apply.
The VIs are attached in the zip file.
Solved! Go to Solution.
Thanks! That works.
What bothers me is that when the dot is there the tools "Performance and Memory" and "Profile Buffer Allocations" both report using twice as much memory as needed, now with the inline it shows no allocations. The windows task manager also shows less memory allocated when using your inline solution. I do not understand why the compiler is making copies here.
I guess the calling VI should not make assumptions on what's happening in the subVI, so it creates two allocations, a second one at the node on the right. (If you would wire the lower array across directly and branch to the subVI, that second allocation disappears.
Thes are hard questions. Maybe sombody from NI should say the last word. 😄
Agreed that these are hard questions.
My problem is that some of this stuff seems like voodoo. A simple "in & out" subVI should not have to make a memory copy. In fact it appears that it does not do that in LabVIEW 2014. Why has the compiler changed in this regard for 2015? Now I need to recheck my programs when updating for memory copies, not ideal.
Check that your inputs are marked as required. If not, then LabVIEW has to allow for the possibility you'll call the VI without the input wired, making it impossible to reuse the input as the output. Possibly this isn't a change since LabVIEW 2014, but maybe you set the option to set inputs required in 2014 and not in 2015 (assuming you recreated the VI, rather than saving back to a previous version).
EDIT: my guess above is consistent with Altenbach's comment about inlining (then the input is always wired) but looking at your screenshot again, it doesn't make much sense why it would matter whether it's inside an in-place element structure.
I still see a dot when changing the inputs to required. Thanks for the suggestion.
Something strange is happening with the IPE structure as Christian has pointed out.
Anyone from NI reading this thread?
Another thought: there's no guarantee that your array contains enough elements, so LabVIEW might have to allocate a new, empty array. You wouldn't see this without the IPE (or with an IPE but without the split, the way Altenbach showed in the nested IPE). I'm pretty sure buffer allocation dots show places where an allocation might (not will) occur.
I'm pretty sure buffer allocation dots show places where an allocation might (not will) occur.
That is what I thought too. However, when profiling with Task Manger in Windows I see a memory reduction when using Christian's solution, roughly 2 data copies worth. Trace execution did not provide many hints either.