LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Mads

inLine subVIs in the background

Status: Completed
Available in NI LabVIEW 2010

If you need to call a subVI millions of times the overhead associated with calling the VI will add up and cause your code to slow down significantly. So - you want to get rid of the overhead...but if you do this by putting all the code in the same VI that VI will look very messy...Well - I want to have my cake and eat it too.

 

As people may know you can get an "Inline SubVI" option in your right-click menu if you add the key inlineSubVIEnabled=TRUE in LabVIEW.ini. This if fine and should be made visible by default, however the way it is done is simply by extracting the code of the subVI and putting it onto the diagram of the caller...which typically leaves you with a big mess.

 

So - instead of graphically putting the code on the same diagram, the inline option should just mark the subVI - you could get a little glyph on it that tells you that it has been inlined. You as the programmer do not need to be bothered with the fact that when the code is linked and compiled the code in that subVI will be inlined into that caller.

 

9 Comments
crelf
Trusted Enthusiast
Yes!




Copyright © 2004-2024 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 4.0 License.
altenbach
Knight of NI

Maybe we don't even need an option. I think it should be up to be compiler to do this automatically if the following conditions are met:

 

* The VI is reentrant (full, not shared)

* the VI is set to subroutine priority

 

(Or maybe add a new priority to the execution option right below subroutine called "inlined").

 

 

 

JackDunaway
Trusted Enthusiast
Excellent! I like altenbach's suggestion of having another execution mode called "inline."
dbrigada
Member
An "inline" priority VI shouldn't necessarily have some of the restrictions that current subroutine priority VIs have, so I'm not sure that this is correct.  The point of inlining in LabVIEW and inlining in most other languages is similar---avoid the function (VI) call overhead.  However, due to LabVIEW's higher function call overhead (must copy all data), inlining is useful for nontrivial VIs.  Large VIs that are used once in an application, but work on a lot of data are good candidates for inlining in LabVIEW, but not in other languages.  An inlined VI should be able to call other non-inlined or non-subroutine priority VIs.
tst
Knight of NI Knight of NI
Knight of NI

...However, due to LabVIEW's higher function call overhead (must copy all data),

From a strict data-flow perspective, this assertion is correct. However, LabVIEW already has numerous tweaks to avoid having to create a copy of the data and instead use the original block of memory. Inlining would only solve that issue in particular cases.


___________________
Try to take over the world!
Marc Blumentritt
Member

altenbach wrote:

 

Maybe we don't even need an option. I think it should be up to be compiler to do this automatically if the following conditions are met:

 

* The VI is reentrant (full, not shared)

* the VI is set to subroutine priority

 

(Or maybe add a new priority to the execution option right below subroutine called "inlined").


Is this done already?

If yes, in which version of LabVIEW?

If no, will it be done?

 

This sounds good, especially for all these smal helper VIs, which I program myself and use alot.

CLD
AristosQueue (NI)
NI Employee (retired)

> Is this done already?

 

No. The idea is still marked as "New". It has not been accepted by NI for implementation in any future version. That's not to say work isn't proceeding in this area, but the particular idea has not been accepted.

Todd S.
NI Employee (retired)
Status changed to: In Beta
 
Todd S.
LabVIEW Community Manager
National Instruments
Laura F.
Active Participant
Status changed to: Completed
Available in NI LabVIEW 2010