LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2015 Buffer Allocation Bug?

Solved!
Go to solution

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.

 

Capture.PNG

 

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.

 

Cheers,

mcduff

 

0 Kudos
Message 1 of 25
(5,110 Views)
Solution
Accepted by topic author mcduff

If you inline the subVI, the allocation disappears.

Message 2 of 25
(5,098 Views)

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.

 

Thanks again.

 

Cheers,

mcduff

 

0 Kudos
Message 3 of 25
(5,088 Views)

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. 😄

0 Kudos
Message 4 of 25
(5,073 Views)

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.

 

Thanks again.

 

mcduff

0 Kudos
Message 5 of 25
(5,067 Views)

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.

0 Kudos
Message 6 of 25
(5,063 Views)

Another interesting tidbit. 

If you use a second IPE structure, the allocation on the subVI (not inlined!) disappears, but the one on the right remains.

 

Hmmmm.....

 

 

0 Kudos
Message 7 of 25
(5,039 Views)

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?

 

Cheers,

mcduff

0 Kudos
Message 8 of 25
(5,033 Views)

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.

0 Kudos
Message 9 of 25
(5,029 Views)

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.

 

Cheers,

mcduff

0 Kudos
Message 10 of 25
(5,023 Views)