Why does priority of NON RUNNING vi affects execution time of subVI?

[CoastalMaineBird]

I'm chasing a weird timing problem. LabVIEW 7.0 + Windows 2000

I have a VI (called "the Object"), whose purpose is to store and retrieve numerical values by name.

The name is hashed, converted to an array index and the values are read / written to an array slot.

That all works fine.


I have a tester for the Object. It generates random names and random values. starts a timer, stores the values (say 1000 of them),marks the timer, reads the values, and marks the timer again. The point is to judge the execution time of the Object.

That all works fine.


EXCEPT


I measure a particular case at 11.44 mSec for 1000 writes. Repetitions result in numbers similar to 11.44

I then lo
ad a particular VI from a program I'm having trouble with. The trouble is it's taking more time than expected to process data.

This VI is normally set to execute at TIME CRITICAL priority.

This VI uses (indirectly) the Object.

If I load this VI WITHOUT RUNNING IT, and run the tester, the execution time goes from 11.44 to 27.08 mSec.

The VI is NOT RUNNING, yet it's presence affects the execution time of a VI it uses.

If I change its priority to NORMAL or BACKGROUND, then the tester reports the shorter times (11.44 or so).

If I change its priority to ANYTHING above NORMAL, I get a 27+ mSec time. I can change it back to normal, and get the "normal" execution time.

Why does a given VI's priority affect it's subVI's execution time IF IT IS NOT EVEN RUNNING?

And how do I fix it?

[CoastalMaineBird]

MORE INFORMATION:

If I put the "Object" VI (normal priority) in a brand-new VI, the tester shows the faster execution time.

If this new VI is set to ABOVE NORMAL priority, the execution time balloons upward again.

If I raise the TESTER's priority to match (or exceed) the new VI's priority, it's back down again.

In other words, it looks like calling a lower priority VI from a higher priority VI puts a "fence" around that lower-priority VI, EVEN IF THE CALLER IS NOT RUNNING.

Other VIs of the same lower priority suffer the penalty of that "fence".

[Ben]

Hi Coastal...

This is just a wild guess.

Is the "object" configured to run in the "Same thread as caller"?

We may be seeing some thread swapping going on here.

Done guessing! Please keep us posted.

Ben


Ben Rayner
Certified LabVIEW Developer
www.DSAutomation.com

[CoastalMaineBird]

Is the "object" configured to run in the "Same thread as caller"?

Yes.
But that doesn't explain (to me) the connection - given that one execution path is not even running, why is the other penalized?

MORE INFORMATION:

If I make the object RE-ENTRANT, the execution time is back to "normal", regardless of priorities. That's not a real solution for me, as I have shift registers within the object I need to keep, but maybe it's a hint as to what's going on.

[Ben]

I agree the re-entrant doesn't get us anywhere but it does tell us something.

When re-entrant we have seperate copies of the VI so one instance ends up in each execution system and there is no need to swap threads.

I suspect the VI just being loaded is enough for force the thread swaps.

If you specify the the thread, how do your numbers look?

Ben

[CoastalMaineBird]

If the OBJECT is set to: the time is :

RE-ENTRANT - NORMAL - SAME AS CALLER 11.2 mSec
NORMAL - SAME AS CALLER 28.9 mSec
RE-ENTRANT - NORMAL - OTHER1 33.8 mSec
NORMAL - OTHER1 29.2 mSec

All of that with the phony caller (that's not running) set to TIME CRITICAL (or anything above NORMAL).

Any clues there? Looks like thread makes no difference...

[Ben]

Sorry for the distraction but,

How about if everything is set for the same thread? This would rule out the thread swapping theory.

Please let us know what you find.

Curious,

Ben

[CoastalMaineBird]

How about if everything is set for the same thread? This would rule out the thread swapping theory.

--- That's where we came in. I just double checked, and everything is set to NORMAL - SAME ExeSys AS CALLER (Non re-entrant).
The times are about 11.4 mSec.
If I set the DUMMY priority anywhere above NORMAL, I get 28 - 29 mSec times.

[CoastalMaineBird]

MORE INFORMATION:
I have attached a simplified version which shows the problem.
I have removed the real "object" VI for contractual reasons. I have substituted a dummy VI.

Run the TESTER, and I get 11 mSec execution time.
Set the priority of the DUMMY CALLER above NORMAL, and run the TESTER again. I get 22-23 mSec.

In other words, the execution time of a VI "A" called by "B" is dependent on the priority of a SEPARATE caller "C", which isn't even running.

THAT I don't understand...

[Ben]

If I set the "wasteTime.VI" as sub-routine, the undesirable effect goes away!

I am guessing that on every call of the waste time VI the non-running VI is checked to see if it wants access to the sub-VI when it is set for higher priority.

This does not naswer your WHY Q!

I'll watch to see if others can expalin this behaviour.

Ben