Why this particular Buffer Allocation?

[Ben]

---

CoastalMaineBird wrote:

Well, I'm one hour into a two-hours test, and the CPU hasn't moved off the 2% mark.  I think you hit the bullseye, once again.

Kudos to you, sir.

Now, I need to take away a rule from this.

I put the terminal inside the case structure because:

• It's only used in one case.
• It's clearer that it's only used in one case, if it's inside that case.
• I didn't think it would make a performance difference.

Since it obviously does make a difference, I need to think about what to do. 

Should I

• Put ALL terminals at diagram root level in all VIs (yuck).
• Wait for a performance problem, and recognize this issue more quickly next time?

I'm generally in favor of increasing performance at every opportunity, regardless of premature-optimizations arguments.  However, I'm not so sure here. 

---

Thank you.

If you read through that clear as mud thread you will see that you are in the position I was when that thread was live. When i used to program in C, I would have to stop and think about the function prototype and how I would pass and return values. When we put together the Icon connector and place its controls and indicators, we are in effect defining the function prototype. So in the same way I was thinking about how to pass and return values in C, I have the OPPORTUNITY to think about and control the syntax of the function call in LV, but I don't HAVE to think about it most of the time.

Yes this a subtle aspect of LabVIEW that do not jump up and grab your attention. For the most part, LV does a very good job at making good decisions and when in question it errs on the side of caution (in your situation LV did not trust that sub-VI not to mess with the data.). By putting the icon connector terminals on the root, you are telling the compiler "Go for it!".

Ben

[CoastalMaineBird]

For the most part, LV does a very good job at making good decisions and when in question it errs on the side of caution (in your situation LV did not trust that sub-VI not to mess with the data.).

--- The key point seems to be that it doesn't assume it WON'T get changed unless it can prove otherwise, it assumes that it WILL get changed unless it can prove otherwise.

Still, in my case, I don't understand, except that maybe there are limits as to how deep it can go before it gives up and says "I better be safe".  There is no possible way that terminal being on the inside or the outside can make a difference, as far as I can see (not that I'm a compiler expert or anything).

On the other hand, in the extreme case mentioned (setting a breakpoint on a subVI, and changing the values on a control after hitting the break), I suppose that If I did that, and the data was "in-place", then that would change the master copy, and that would violate the intent of the diagram.

But I don't see how that is changed by moving the terminal.

By putting the icon connector terminals on the root, you are telling the compiler "Go for it!".

It's just not very obvious that that is what I'm telling it.  It's obvious to me that data could not be changed by that subVI, I'm just baffled because the compiler has doubts.

In any case, my plans for a compiler-writing career are now dashed ;->

Also, the two-hour test finished with no deviation from the 2% usage mark.

Thanks again, Ben 

[CoastalMaineBird]

Just for the record - I went back an re-established the original problem (where a sub-subVI's terminal was INSIDE a case structure), and I got the unwanted allocation back.

I then re-created this situation, that I mentioned before:

It still showed the unwanted allocation, even though there's nothing for the array to connect to but the ARRAY LENGTH function.

I thought this odd at the time.

But if I delete the broken piece of wire, the compiler has another chance, and the allocation is removed, as expected.