Explain timing anomalies with references

[CoastalMaineBird]

I have a TIMING TEMPLATE which I have used for years to time various LabVIEW operations and decide whether do do something this way or that way.

Basically, it does this:
FRAME 0: { Any initialization goes here, normally empty }
FRAME 1: T0 = mSec timer
FRAME 2: For i = 0 to N-1 do Nothing { usually empty loop, used to subtract the loop-processing time out }
FRAME 3: T1 = mSec timer
FRAME 4: For i = 0 to N-1 do ( WHATEVER )
FRAME 5: T2 = mSec Timer

The time to do WHATEVER is then ((T2-T1) - (T1-T0) ) / N
where N is a front panel control to determine how many times to repeat the operation. If N is a million, then you get an accurate answer, down to nanoseconds if you want.
It's worked very well for a long time.

So today, I found this weird behavior and want to find out why.

I was trying to evaluate the speed of passing a boolean value from one place (in a large project) to another, without wires. On the front panel of the timing VI, I put a boolean indicator, and hid it, so that the actual drawing rime wouldn't be counted.

So inside the FRAME 2 loop, I put the following code:
NewValue = (i mod 2) == 0
ShiftReg = NewValue
That is code to alternate the state of the indicator, that I don't want to include in the timing.

So inside the FRAME 4 loop, I put the following code:
NewValue = (i mod 2) == 0
ShiftReg = NewValue
Ref = (Ref to Indicator)
Ref.Value = NewValue

The difference between FRAME 4 and FRAME 2 is exactly what I wanted to time.

So that answer comes out as 10.32 uSec. I am dismayed at that slowness, but I believe it to be true (property nodes have always been slow).

Just in playing around, I moved the REFERENCE node OUTSIDE of the loop. I would expect this to have only a slight impact on the execution time, and that impact would be positive. After all, instead of doing it 100,000 times, I'm only doing it once.

That one little change made the execution time go from 10.32 uSec to 35.98 uSec. OVER THREE TIMES the time!

WHY?

[tst]

How about posting it?
You know we do much better when we have what to play with.

As a wild guess, based on the description, maybe the fact that the reference is out of the loop forces LV to do more work because a reference isn't just a wire with data, but actually requires that the control be updated. Maybe when the reference is outside the loop, LV doesn't check to see if the wire is split and if the ref is used elsewhere (or something)?

Post the code...

[CoastalMaineBird]

Attached is the timing code.

In the process of packaging it, I tried it on OSX LabVIEW 7.1 (The original case was Win2000, LabVIEW 7.0)

The original case was 9.5 uSec (inside) and 36 uSec (outside).
The Mac case was 7.9 uSec (inside) and 480 uSec (outside) - a MUCH greater difference.


Still it makes no sense to me. I just want to understand what exactly the cause is.

[tst]

It seems that using an explicitly linked property node is the same as placing the property outside the loop.

My guess would still be that because the reference itself is out of the loop, LV probably does some additional checking or something in every iteration, but that is really based on no facts.

[CoastalMaineBird]

My guess would still be that because the reference itself is out of the loop, LV probably does some additional checking or something in every iteration, but that is really based on no facts.

But I could understand that. If it took LONGER when the reference was INSIDE the loop, I could say that LV is checking the validity of something. That's why I expected the result to be slightly SHORTER when I moved it outside - it would perform the check ONCE and then just USE it.

But it's the other way around - it takes LONGER when it only does it ONCE !!!

Why is that?

[tst]

I refered to that in my first post and said that my guess was that this is behavior is different because a reference is not just a value passing through a wire.

For example, let's say that if the reference comes from outside the loop, LV has to check whether it's valid in each iteration, but if it comes from inside the loop, it knows it's an explicit ref and doesn't need to check. Such a behavior would probably be categorized as needing to be optimized, but that was just an example (and I'm not saying that this is how LV behaves, it was just something I made up).

[CoastalMaineBird]

if the reference comes from outside the loop, LV has to check whether it's valid in each iteration, but if it comes from inside the loop, it knows it's an explicit ref and doesn't need to check.

I see. I misunderstood your previous post.

That sounds like a reasonable explanation, if you assume that checking a reference's validity is a lengthy operation. And apparently it's way more lengthy on OS X.

From what I've seen, any operation with references or property nodes is quite time-consuming.

[Ben]

I am leaning towards tst's explaination.

LV appears to leave out something when the reference is inside the loop. If you compare the code size for the two versions, the inside is 4.9K and the outside version is 5.1K.

That 200 bytes seems to make a big difference. I wonder if a validity check can be done with only 200 bytes of code. I suspect some type of optimization, maybe "folding"?

Ben

[Ben]

I am leaning towards tst's explaination.

LV appears to leave out something when the reference is inside the loop. If you compare the code size for the two versions, the inside is 4.9K and the outside version is 5.1K.

That 200 bytes seems to make a big difference. I wonder if a validity check can be done with only 200 bytes of code. I suspect some type of optimization, maybe "folding"?

Ben

Sorry for the double post! I'm learning how to mouse with my left hand to let the right hand recover from a bad day on-site with poor ergonomics.

Message Edited by Ben on 09-07-2005 03:59 PM

[tst]

Actually, I think I would vote against the validity check (I just suggested it as an example) because an explicitly linked property node (which should probably have no validity check) performs badly.