Why this particular Buffer Allocation?

[CoastalMaineBird]

OK, so I moved the sub-sub-subVI's terminal to the ROOT of it's diagram:

There's still a buffer allocation there.  The calling VI shows no change (there's still an allocation at the terminal, though I didn't circle it):

 

However, the calling VI to THAT one DID change:

 

This allocation is GONE!  I suspect that this solves the problem (though I'll have to set up another two hour test to prove it). 

[CoastalMaineBird]

LabVIEW can recognize the "wired-through on the root" code pattern as "data not modified".

OK, but that can't be the only trigger.  In my case, the data is not wired through at all. 

I'll start up another test, and go read that thread.  There's got to be something I'm missing.  I put the terminal inside a case because that was the only case that used that terminal, and that fact is clear if it's inside.  Putting it outside means it's not immediately clear that the terminal is not used in any other case.

It's a bad situation when clarity of code is on the opposite side of performance. 

[CoastalMaineBird]

Well the array size function is in all your case's so to be pedantic it should be done outside of the case strusture.

--- I think you're misunderstanding the pics I showed, there is only one ARRAY SIZE function call. 

[CoastalMaineBird]

I suspect that you can solve this, or at least narrow it down further, by having the setpoint array pass through the case structure and back out to the shift register, rather than forking the wire at the top. 

But that makes it even less obvious (to the human observer) that the array is not going to be changed here. To figure that out, you would have to follow the wire thru all paths.  Forking the wire means (to me, anyway) that the "master" copy is not influenced by anything the subVIs may do. 

[CoastalMaineBird]

Sorry, Ben, but your link to the "clear as Mud" thread is gorched, and I am unable to find it thru searching.

Do you have a working link? 

[CoastalMaineBird]

If simply doing the wire through to that sub-VI and its sub-VI is not enough to get the in-placeness to change its mind

This might be a key point: "changing it's mind" 

The fact that I could break a wire, leaving the connection ONLY to an ARRAY LENGTH function, and it STILL had a buffer allocation there, says that LabVIEW isn't making the decision everytime it compiles.  It had decided to make a buffer some time ago, and breaking that wire wasn't enough to trigger a re-evaluation of that (even though it should have).  The tunnel was marked, somehow, as needing it, and so it was going to get one, even though the reasons for it being needed were gone.

That's not good news. 

[nathand]

---

CoastalMaineBird wrote:

If simply doing the wire through to that sub-VI and its sub-VI is not enough to get the in-placeness to change its mind

This might be a key point: "changing it's mind" 

The fact that I could break a wire, leaving the connection ONLY to an ARRAY LENGTH function, and it STILL had a buffer allocation there, says that LabVIEW isn't making the decision everytime it compiles.  It had decided to make a buffer some time ago, and breaking that wire wasn't enough to trigger a re-evaluation of that (even though it should have).  The tunnel was marked, somehow, as needing it, and so it was going to get one, even though the reasons for it being needed were gone.

That's not good news. 

---

I'm not so convinced on this one.  I assume you did save/recompile the VI after breaking that wire and before checking buffer allocations; if not, that's the easy explanation.  I could believe that LabVIEW might not do a full recompile if it detects a broken wire - why bother, if the VI can't run?  If that's the case it would explain what you describe.

[Ben]

The show buffers only updates after a save of a GOOD VI. If its broken it can't be sure.

The Clear as Mud Thread can be found here

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=191864#M191864

To find this thread just search on "Clear as Mud" and find the link with Greg McKaskle2 in the serach results.

I will not to repeat what Greg said here. He is very good at explaining things so please read (and Kudo) his postings in that thread. He covers all kind of ideas that we don't normally stop and think about like "If an output terminal on the icon connector is only updated in a case that is not executing, what doe sthe VI return to the caller via that terminal" etc.

As of the time of that thread, the VI Analyzer had a test that would look for situations where terminals were not on the root and will show them to you.

For the time bieng my money is still on "wire-through" and get rid of that wire branch.

Ben

[CoastalMaineBird]

  I could believe that LabVIEW might not do a full recompile if it detects a broken wire - why bother, if the VI can't run?  

OK. you're probably right. I didn't give it a chance to re-evaluate everything.

[CoastalMaineBird]

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.