case structure parameter efficiency

[bjlv]

You have been fooled by the terminology of the priority settings in LabVIEW.  Most people never get into this, but you can change the priority of execution (when several parallel subVIs might be next to execute) by changing the subVI priority among several choices.  The fastest is "subroutine", but that puts some limits on what the subVI can do because it throws out some options in order to get the speed.  The help should give you some ideas about this if you want to read more.
Bart

[tst]

---

@greg wrote:

But what if you had a breakpoint set on the subVI. At the breakpoint, the panel is open, and you type in new data. Oops. The caller is supposed to protect the data, but if the terminal is conditionally read, it can't predict you won't do what I just described. On the otherhand, if the terminal is on the top level, the breakpoint on this VI will always happen after the data from the terminals is read. That means the subVI can truly be inplace only if its terminal is owned by the top diagram and not placed into a loop, sequence, or case diagram.

---

Although, since breakpoints are exposed in the VI server object hierarchy, it should be theoretically possible to only copy the data if a BP has been set, wouldn't it?

Or would that take up too much resources?
Or maybe there are other cases where you couldn't guarantee the inplaceness?
See what you get when you expose the decision making process? A lot of pests second-guessing your decisions...

BTW, I'm fairly sure that the part about placing the terminals in the root of the diagram has been documented in the style guide, so you should be alright there...

[eaolson]

---

@greg McKaskle2 wrote:
That means the subVI can truly be inplace only if its terminal is owned by the top diagram and not placed into a loop, sequence, or case diagram.

---

Just to be clear: this slowdown will happen inside while loops, for loops, and squence structures, and is not specific to case structures? I guess I've always thought it was the other way around, and put terminals inside structures when I could.  Oops.

It seems like I learn something new about Labview every day.  When will I be finished?

[Greg_McKaskle2]

Yes, explaining why the sky is blue can be difficult, especially if you don't completely understand it yourself. But to try and understand it well enough to explain it is often the best motivation to learn it.

So, the main thing to note here is that the copies happen at the caller, not really at the subVI. The subVI is compiled either using its caller's data or its own. If the decisions are being made at runtime, you are sliding towards an interpreted system, and the performance will always be slowed. To better explain this, there may be fifty places in a VI that generate code that accesses a piece of data in the subVI. To access either A or B after looking for breakpoints at each of these probably isn't a win, especially since there usually will not be a breakpoint. To generate the code to always access B, and move A to B is likely to be better, especially in the normal situation.

By normal, I mean that this test is again a bit rigged. We have a monster constant that must be there each time the VI is run. This means that the big data must be copied in order to be preserved. In a more normal situation, the data is not constant, and can be top-copied, meaning that copying an array of several million elements in a constant means copying several million elements. Copying several elements that aren't constant means swapping the array references, or copying about eight bytes.

I encouraged Darren to add this test when I discovered the rather big cost of terminals being in inner diagrams. I sort of understand it, but that doesn't mean I can totally justify it. It seems like there are some things that can be done better since there usually isn't a breakpoint there, and even if there is, the user probably won't change the input params. We have talked about some things to improve it, but they will take time to implement. In the meantime, if you don't have a UI reason for putting a terminal inside a loop, and if the subVI is called often, I'd put it in the top diagram. And that is what Darren's test will help remind us of.

Greg McKaskle

[Ben]

Hi Greg eta al,

I think I got it!

The attached code an image illustrates what I concider a common construct that illustrates the point.

In the "good" version, the control and indicator are on the root of the diagram and LV can see that the array of the caller can be the same VI inside the sub-VI and the same with the returned data.

The "bad' version force a data copy.

On my laptop an array size of "1000000" and loop count of "1000" and error is "false"

Good = 1uSec

Bad = 23 mSec

With error = True

Good = 1uSec

Bad = 47 msec

Generally, the time required for "Bad" scales with array size (because of the copy) while "Good" is fixed up untill you run out of physical memory.

Thanks Greg!

Ben

Message Edited by Ben on 06-25-2006 10:28 AM

[rolfk]

LabVIEW and I must just be very close friends. This is what I have always done when programming LabVIEW, not exactly because I knew it will be the best, but because I felt that this would result in the best execution performance. Some people ridiculed me a few times for spending the extra time about wiring these extra wires, but this proofs that I had been right all the time

Rolf Kalbermatter

[Ben]

Rolf wrote;

"I had been right all the time  "

After reading your posting for 7 years now, I have to agree.

Ben