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

[Marc Blumentritt]

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.

Regards,

Marc

[Mr.Mike]

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.

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 A.vi, which calls B.vi, which calls C.vi (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.

[CMal]

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 

[Mr.Mike]

@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 today...my foot doesn't taste too good.

[Darren]

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