Explain timing anomalies with references

[CoastalMaineBird]

an explicitly linked property node (which should probably have no validity check) performs badly.

I assume by that you mean a property node created by CREATE PROPERTY NODE (which I would call implicitly linked because I don't have to link it).

I agree - I would think that no validity check would be required.

For the record, here are some test numbers. (LV 7.1, OS X, 2x2.0GHz G5)

Directly setting the value, thru the terminal: 0.52 uSec.

Setting the value thru a direct property node (created by CREATE PROPERTY NODE) 501 uSec.

Disconnecting that property node from control (it becomes "Boolean(strict)") and providing a reference INSIDE the loop: 8.77 uSec

Same as above, but reference is outside the loop: 438.6 uSec

Creating a property node from VI SERVER palette (it becomes "Bool (Strict)" - what's the difference?) and providing a reference INSIDE the loop: 14.2 uSec

Same, but reference is outside the loop: 423.8 uSec

I have no idea what the diff is between Bool and Boolean.

The fact that the direct property node is so bad, suggests the validity check is not the explanation.

It's obvious that I should avoid property nodes if at all possible when speed is an issue. But they server a useful purpose - I'm just not sure what the rules are to maximize their speed when I need to...

[tst]

Which term we use is another debate (I called it explicit because LV [not us] knows that which control it is linked to, and it can only be connected to that control, but I can see how implicit would apply better), but we are talking about the same thing.

If there is a difference between Bool and Boolean (your numbers weren't far enough to determine that), then as another wild guess I would say that maybe one of them is an older one which was replaced, but using it requires a conversion to the newer one.

[modicon]

Try closing the Refrence inside the loop....it gets much faster..

[modicon]

...oops...ignore previous post....closing ref slows it down a tad...

[Jack J.]

Here is something even stranger. If you place the reference outside the loop and NOT CONNECT IT TO ANYTHING. Link the property node directly to the control, it still takes a long time. If you bring it inside the loop, it cuts the time short (still not connected to anything)

This might mean that LabVIEW does some optimization when inside the loop that it doesn't do outside. Hmmmm.

Jack J.
Applications Engineer
NI

[Dynamik]

Just wanted to do my part to further confuse what's happening.  After dropping an empty single-frame sequence inside both the four-loops of the original example, the calculated time-per-execution increased by a factor of 3.

Regardless of current questions, nice timing-test example CMB - clever the way you isolate the target code's affect - liked the arrow-decorations too! 

Message Edited by Dynamik on 09-08-2005 08:08 PM

[CoastalMaineBird]

Just wanted to do my part to further confuse what's happening.
--- Why, thanks. We need all the confusion we can get ;->

After dropping an empty single-frame sequence inside both the four-loops of the original example, the calculated time-per-execution increased by a factor of 3.
Hmm, I tried that on OSX - I got basically the same results as moving the reference outside the loop - 500+ uSec instead of 9.0 !

That makes no sense - the SEQUENCE code should be optimized away.

It does suggest that meybe it's something to do with threads, execution systems, something like that.

Regardless of current questions, nice timing-test example CMB - clever the way you isolate the target code's affect - liked the arrow-decorations too!

Thanks. Been using that for years. I needed a tool to tell me nanoseconds resolution using a millisecond clock. I'm all the time trying to figure out if method A is faster than method B.

[CoastalMaineBird]

Hmmm - here is more interesting info. After your SEQUENCE-MAKES-IT-SLOWER discovery, I thought I'd check out priorities, and execution systems.

The priority and re-entrancy seems to make no difference.

Using the STANDARD, INSTRUMENT, DAQ, OTHER, or SAME AS CALLER ExecSys makes no difference.
But if I set it to run on the USER INTERFACE ExecSys, it runs exactly as I would expect - slightly (only slightly) slower when the reference is INSIDE the loop, than when it is OUTSIDE.

Adding the SEQUENCES (to both loops) makes no difference, as you would expect.

That does nothing to EXPLAIN it, though. If it was some sort of cross-ExecSys overhead, I would still think it would affect us less OUTSIDE the loop than INSIDE.

[CoastalMaineBird]

This might mean that LabVIEW does some optimization when inside the loop that it doesn't do outside.

Well, I suppose that's possible. If you're going to limit the amount of optimization you do, then it makes sense to do it first on the stuff that gets done more often (stuff inside loops).

Although, that still doesn't explain everything. It must take a LONG time to do something if doing it ONCE affects the result by that much.

[Dynamik]

I did as you described and got similar results - that is:

addition of sequence(s) makes a (~3x) difference when executing in subsys "Same as caller"

addition of sequence(s) makes no (obvious) difference when executing in subsys "User interface"

If I neglect my employer to pursue this puzzle any further, it will be with subsys=UI - to help suppress noise.

Nice observation!

....and so, in UI thread, I moved the reference in/out of the loop and it [now] seems to run a bit faster with reference outside loop - as you would expect!