Inline vi and shared clone execution Win vs RT

[bsvingen]

In general, when inlining is hooked does it matter if you use share clone or preallocated clone?

And then when using RT, the help files say preallocated is best, but what if you inline the code?

thanks

[Rolf Kalbermatter]

In general, when inlining is hooked does it matter if you use share clone or preallocated clone?

And then when using RT, the help files say preallocated is best, but what if you inline the code?

thanks

Why do you think that the reentrant setting would still have any influence when VIs are inlined? Basically they then all have their own data space AND code path anyhow (using the data space of the VI they are inlined to and the code path which is copied verbatim into that VI), so no possible contention from having to protect data space and/or code execution from multiple concurrent accesses.

And RT has no influence on that. Preallocated is best on RT as it minimizes the amount of memory allocations and reallocations, but since there are no clones that could compete for data space allocations anyhow here, this setting is again irrelevant for inlined VIs. That doesn't mean it has to be irrelevant for the VI that contains the inlined VIs but I think that should be obvious.

[bsvingen]

Why do you think that the reentrant setting would still have any influence when VIs are inlined? Basically they then all have their own data space AND code path anyhow (using the data space of the VI they are inlined to and the code path which is copied verbatim into that VI), so no possible contention from having to protect data space and/or code execution from multiple concurrent accesses.

And RT has no influence on that. Preallocated is best on RT as it minimizes the amount of memory allocations and reallocations, but since there are no clones that could compete for data space allocations anyhow here, this setting is again irrelevant for inlined VIs. That doesn't mean it has to be irrelevant for the VI that contains the inlined VIs but I think that should be obvious.

Thanks. I just wondered, since the options can be hooked on/off even when inlined and I could not figure out why. For instance, if the compiler for some reason didn't want to inline the code after all, THEN the vi would be either a single clone or several based on the setting. Not much info about this.

Also, "subroutine" for inline code makes no sence, unless there are som catches somewhere.

So you are saying there are no catches, inline is inline no matter what and RT makes no difference.

[Rolf Kalbermatter]

Thanks. I just wondered, since the options can be hooked on/off even when inlined and I could not figure out why. For instance, if the compiler for some reason didn't want to inline the code after all, THEN the vi would be either a single clone or several based on the setting. Not much info about this.

Also, "subroutine" for inline code makes no sence, unless there are som catches somewhere.

So you are saying there are no catches, inline is inline no matter what and RT makes no difference.

I wouldn't hold my hand in the fire and promis that inline will be always inlined, but I was under the impression, that unless you do something else non-standard in the VI settings, this should be the case anyhow. It's possible that a newer LabVIEW version might introduce a threshold which when the VI is above that in terms of some complexity would prevent the VI from getting inlined, but I'm not aware of such an option yet (which of course doesn't mean it couldn't be already there)!

[asbo]

I agree with rolf - there *shouldn't be* any exceptions where a VI configured to inline won't inline, but only NI could tell us for sure. The fact that some VIs see a performance decrease from inlining tells me that, at minimum, LV is not disabling inlining conditionally as an optimization. The only conditions I know of that break inlining are those made verbose by the exclamation icons in the Execution settings pane of the VI.

Also, "subroutine" for inline code makes no sence, unless there are som catches somewhere.

In non-inlined code, it is guaranteed that a subroutined VI will execute as one clump (that is, atomically). I would hope that holds true for inlined code, but that's something else I can't speak to.