Darren's Weekly Nugget 10/18/2010

[Broken_Arrow]

---

@LuI wrote:

---

@broken Arrow wrote:

This feature is not to be confused with the JKL right  mouse click option "Inline SubVI", which literally (and neatly) converts the VI to code onto your diagram. Different but the same, kinda.

---

AFAIU (...understand) thi is not really 'the same' as it puts a copy of the code into the callers BD, while inlining keeps the callee alone. Maybe like a macro for text-based compilers?

---

Well... that's why I said "Different but the same, kinda". While being less than perfect English on my part, it still should get the point across. At least more so than "AFAIU".

[Marc Blumentritt]

Hi all,

is there any reason against inlining every VI, that is reentrant? If not, why not make this automatically?

Regards,

Marc

[Darren]

---

is there any reason against inlining every VI, that is reentrant? If not, why not make this automatically? 

---

The LabVIEW Help lists some tradeoffs associated with inlining subVIs.  See here for more information.

[Marc Blumentritt]

---

@Darren wrote:

The LabVIEW Help lists some tradeoffs associated with inlining subVIs.  See here for more information.

---

In my opinion the italic part of the following sentence is a little bit misunderstanding:

---

A subVI you inline cannot contain recursion, and all calling VIs of the subVI must be static. Also, when you inline a subVI, LabVIEW ignores any priority, reentrancy, or preferred execution settings.

---

I read this like this: The calling VI of the inlined sub-VI must be static. This is certainly not true. It should be written like this: every call of a inlined sub-VI must be static.

To sum up: do not use inline, when you want

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 d'ont want to recompile every time, when you change the reentrant sub-VI

I think, inlining reentrant VIs can be enabled by default. Of course, the programmer should be able to disable inlining. Perhaps this is something for a LabVIEW option?

Regards,

Marc

[Darren]

I agree...that sentence is misleading.  I have filed CAR# 286042 to fix the documentation.

As for your suggestion that we provide an option to have inlining on by default for reentrant VIs, please consider posting it to the Idea Exchange.

[MichaelAivaliotis]

So as far as I understand, in a built executable, the VI which is inlined is still available by name. It still physically exists. The inlining is done in memory. - correct?

[JÞB]

Mike,

Perhaps Darren was a bit overstated when he said inlining "Eleminates" sub-vi call overhead (although technically correct)  a vi calling an inlined sub.vi is compiled just as is if you wrote the vi and dropped the contents of the inlined sub.vi on the calling vi's BD inside a single frame sequence structure (but without the BD size hit).  There is a synchronization barrier around the inlined sub-iv but, sub-vi call overhead is gone, not, nil, zero.

Somewhat more overhead than just JKI -inline (Unless I miss the tool's function).  Clones must be in ther own namespace but the clone original will be preserved in the build and source distributions.

Debugging an exe with an inlined sub-vi is no different than with any reenterant sub-vi but I f I needed the perfomance advantage of inlining (and sometimes I do) the debugging would be gone in an exe anyway.

``` Glad to see you on the dark side``` I don't often step into the light