When do you use Subroutine priority?

[Jim_Kring]

[cross-post]

There is a VI execution priority setting called subroutine. Explainations of this setting can be found here:

• LabVIEW Help >> Execution Properties
• LabVIEW Advanced Programming Techniques >> 9.10 Subroutines in LabVIEW

While I understand some of the basic principles of the subroutine setting, I'm not 100% certain about the best practices and rules of thumb for when to apply this setting and when to avoid it.

Does anyone have any thoughts on this matter?

Note that this questions applies to a design decision in a new OpenG candidate.

After this discussion, I'd be happy to consolidate the information into a Subroutine page on the LabVIEW wiki.

[Jarrod_S.]

I use it for relatively small "utility" VIs that will get called repeatedly. Subroutine VIs should always finish in a bounded amount of time. They shouldn't contain any loops that could run forever. They obviously can't contain any functions that block, such as a Wait ms function or any function with a timeout.

Also any VI that you might ever want to call from another subroutine VI must itself be subroutine.

Honestly, most all of the OpenG VIs are great candidates for subroutine priority. For instance, the Array manipulation VIs would make great subroutine VIs. It would greatly limit the overhead of calling them in a loop.

[Jim_Kring]

Hi Jarrod,

Thanks for the feedback.  I, too, was thinking that most of the OpenG VIs are great candidates for the subroutine setting.  Sometimes, when I am trying to optimize my own applications, I will make a copy of the OpenG VIs in my project and set the copies as subroutine priority.  I have found that this can often yield significant improvements in performance.

One thing that I'm wondering about is...

In addition to the (probably) obvious reasons why you can't set a VI as subroutine (e.g., when LabVIEW won't let you due to calls to non-subroutine VIs or dialog functions), when wouldn't you want to make a VI into subroutine?  You've mentioned that you wouldn't want to make a VI a subroutine...

• when a VI contains a While Loop that might never complete
• when a VI might not finish in a bounded amount of time
• when a VI is not relatively small
  

I'm wondering about that last one.  How many nodes is a "relatively small" block of code?  What sorts of metrics would you apply, here. (I know this is a tough question, which is why I'm asking in )

Thanks,

-Jim

[altenbach]

I remember discussions elsewhere from long ago, that there are other possible problems. I no longer have my notes but I stopped using subroutine in most cases because the arguments seemed valid.

Long ago I complained that most plain tranforms (e.g. fourier) and linear algebra tools are NOT subroutine, which prevents them from being used inside subroutine VIs. (Sure, with gigantic amounts of data, they won't be fast).

Sometimes, there are backdoors though. For example if you try to invert a matrix using linear algebra (top) inside your subVI, subroutine is prohibited. If you use a matrix datatype and use the plain invert primitive (bottom), you get the same result, but subroutine priority is allowed. Go figure!

Message Edited by altenbach on 04-01-2008 12:42 PM

[pallen]

I wonder if this setting would be ideal for something like a Functional Global or an "Action Engine"?

[Jim_Kring]

---

@pallen wrote:
I wonder if this setting would be ideal for something like a Functional Global or an "Action Engine"?

---

It would probably depend a lot on what's happening (what code is being called) inside the Functional Global.  If it's only doing a get/set value from/to shift register or performing data manipulation operations in the method frames, then it might help out.  However, this might only result in noticeable improvements for applications that call the functional global a lot.

[Jarrod_S.]

One possible advantage to using subroutine priority in Action Engines (that I've never used) is the ability to "Skip Subroutine Call if Busy." This could theoretically be useful in RT applications where you write to an AE from a background task and read from the AE in a time-critical task. You might not want the time-critical task to block if a background task is busy setting some data or performing a calculation on it. This "Skip..." option allows you to do that.

Again, I've never done that, and these days there are better means of sharing data in a deterministic manner like the RT FIFOs, but it's worth knowing.