> Hmmm - that works for me too. In the real case, the "Object" has a > subVI which has a subVI. I have to set those to subroutine as well, > because a subroutine cannot call a non-subroutine priority VI. But I > think that's OK, in my case. > If I do that, I get times of 8-9 mSec on the real object! > > I didn't try subroutine because I thought it would be the same as the > other above-normal priorities - guess I was wrong. > > Still don't understand why, though. >
I can explain why the subroutine will be faster than the other priorities, so I'll do that first. Subroutine VIs are compiled with less code. They are not debuggable, their panel is totally ignored, even if open, they cannot be suspended, and they do no scheduling (which is why they cannot contain or call asynchronous functions). So subroutines are compiled more like a single blob of code with most of the niceties turned off. Priorities on the otherhand, have little to do with how the VI is compiled, but with which OS thread os asked to execute. Priorities do not speed things up, they just determine who takes cuts in line. They don't work like an accelerator, they work like a horn. Regular VIs are greatly affected by whether the panel is in memory and whether the panel is open. I suspect that you have eliminated these affects, but it is always worth restating. After any of these changes to priorities, perform a Save All before taking any timings. So, what happens when a VI is shared between multiple callers at different priorities. The subVI can only be run by one of them at a time, assuming it isn't reentrant, and if its preferred priority is set lower than one of the callers, it will be boosted to match the higher of the callers. I'm not totally sure when the boosting takes place. If this hapens at reserve time, then it shouldn't affect runtime performance like you describe. If it happens on each subVI call, then it will have some effect, though I wouldn't expect as much as you describe. For now, it sounds like you might want a subroutine anyway, and I'll ask around at work. Greg McKaskle
