LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 
Marc Blumentritt

Inlining VI should by default be activated, if VI is made reentrant

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined. 

Inspired during discussion in this nugget of Darren:


In my opinion there are a lot of good reasons to inline nearly every VI, which is reentrant. I see only three reasons for not using inlining:


1.) use recursive code (which I seldom use)
2.) call the reentrant VI dynamically (which I use more often than recursion, but still I use this seldom)
3.) you don't want to recompile every time, when you change the reentrant sub-VI


Of course you can disable inlining, if you want. It is only enabled after you set the VI reentrant. This behavior could be controlled via LabVIEW options.




NI Employee (retired)

Thank you for your contribution Marc.  Sorry if you got an email with my original comment, which tore your suggestion apart.  I misread the suggestion and thought you wanted to turn on inline for all VIs, not just all reentrant VIs. Smiley Surprised


However, I'm still not too keen on this idea. 


Inlining a VI actually places the compiled code from the inlined VI inside the calling VI.  If you had, which calls, which calls (and lets say B calls C 4 times), then A will be the size of the compiled code on A + the size of compiled code on B + 4x the size of the compiled code in C.


Turning inlining on means you need to turn debugging off.  I don't think that's good because there are plenty of times you'd want to debug.  I think that making some VIs inline should be done as an optimization step near the end of development.


Finally, 99% of the time that I turn on reentrancy is for recursive VIs.  So, I'd need to turn on reentrancy and then turn off inlining.

-- Mike
Active Participant

Quoting Mr. Mike:

"I think that making some VIs reentrant should be done as an optimization step near the end of development."

I would rephrase this statement to say that turning off debugging should be done as an optimization step.  Making a VI reentrant can significantly alter the behavior of your code, so it should be done (when appropriate) early in development.


I'm a big fan of the inlining feature, but it can cause problems if it isn't used carefully.  Like Mike said, inlining a sub VI that is called in many locations can dramatically increase the size of the caller's compiled code.  Because of this, I'm in favor of keeping inlining as an opt-in option for each VI.


Chris M 

NI Employee (retired)

@CMal: I meant to say making some VIs inlined should be done at the end...I'm going to ask for that to be editted since it's a big difference


I really ought to stop talking for foot doesn't taste too good.

-- Mike
Proven Zealot
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined. 

DNatt, NI