case structure parameter efficiency

[jspaarg]

While this probably makes no difference in an application...  I come from an embedded background where code efficiency is always a big deal.

With that in mind, I am curious...

Assume a T/F case structure in a sub VI.

Three parameters are passed that are used only if the case evaluates to "True"

Is is more efficient to put the parameters inside the True case only,

or put the parameters outside the case structure and wire them in, and only use them in the True case?

Answers are appreciated.

[Ben]

" I am curious..."

Your Q had the same effect on me.

I wrote illustrated benchMark VI's to make sure I would get this right.

It appears the answer to your questions depends on the state of the booelan most of the time.

By using a large array to exagerate the act of reading the control I oberserved some interesting things. It looks we ahve three situations that are coming into play.

1) Not reading the control (because it is in the true case and the boolean is false)

2) Reading the control conditionally (Again control in true case but now boolean is true)

3) Always reading the control.

My findings indicate that

Fastest - Not reading the control

Medium - Always reading the control

Slow - Conditionally reading the control

To me this makes sense. Not doing anything should take less time than doing anything. A control on the root of a diagram lets LV do its thing and optimize the operation. Still slower than doing nothing. The conditional read seems bad.

Thanks for the question!

Ben

Message Edited by Ben on 06-22-2006 06:47 PM

[Darren]

You got it right, Ben.  If a control or indicator is wired on the connector pane, terminal reads/writes are always most efficient if they are done on the top level diagram.  In fact, there is a test that ships with the VI Analyzer 1.1 called "Wired Terminals in Subdiagrams" that looks for violations of this very rule.  Here is a sample failure message of that test:

"The control terminal "Numeric" does not reside on the top-level diagram.   In order to avoid unnecessary memory copies, control and indicator terminals that are wired on the connector pane should be placed on the top-level diagram."

...and for those of you who recognize this name, Greg McKaskle is the one who requested I add a test to check for this in VI Analyzer 1.1.

-D

[Ben]

Darren wrote;

"The control terminal "Numeric" does not reside on the top-level diagram.   In order to avoid unnecessary memory copies, control and indicator terminals that are wired on the connector pane should be placed on the top-level diagram."

So that is what that test (I disabled in my configuration) was for!

Ben

[shoneill]

I appreciate this new information.

Great question.....

But why?  Thread-swapping? Memory allocation?  Without a solid background in Programming, perhaps I fail to grasp why this is the case.......

Can someone enlighten me please?

Shane.

[jspaarg]

Thanks to Ben for the test.

I hadn't realized that I could just put in stop watches and check elapsed time.

However, since Windows can vector off for no apparent reason (as it is not a real-time OS), can the fact that it can go and service a network packet (e.g) have an adverse effect on the test measurement?  I would think that it would be necessary to run the test a statistically significant number of times and eliminate any outliers.

To Darren: pardon my ignorance, but what does the term "connector pane" mean?

To shoneill: Is your question related to why I asked the question, or why the timing data shows what it does?

[Kevin_Price]

Yeah, I'm curious about the "why" too.  I remember doing similar benchmarking some years back for RT work and being a little surprised that I was better off keeping the controls and indicators outside any case structures.  A nice side benefit was the legibility of making sure all wired inputs and outputs could naturally be brought toward the extreme left or right rather than being hidden away inside a case structure.

-Kevin P.

[Darren]

Hey guys,

I'm not sure about the exact reasons either...I'll see if I can get someone to enlighten us.

To answer the previous question:  The connector pane is the terminal configuration of a VI that allows you to wire inputs and outputs to it when using the VI as a subVI.  Check the LabVIEW Help for "Connector Pane" for more information.

-D

[shoneill]

I meant why it's slower to have a conditional read.  If it's slower, there's more work being done, so the question was what work is being done in the background to make it slower.

The question itself is great.  It's not something which would EVER have occurred to me, but now that I know the answer, I'll never forget it.

Thanks

Shane.

[jspaarg]

Duh, I know what the connector pane is, it's just that when you right-click on the icon it says "Show Connector".

I should have realized that it is considered a "pane" (no pun intended).