Benefits of the Inline scripting feature

[Ami]

Hi,

Can anyone please explain to me what are the benefits of "Inlining" a LabVIEW project (I say project because I mean a very big system developed in LabVIEW). I understand from previous posts that it decreases execution time, but does it have any effect on Projects that are being run as a stand alone executable? Because, I would assume that when an exe file is being built, the compiler already makes the execution as efficient as possible, thus probably using the same techniques that one of them is "inlining".

Thanks,

Ami

[Mellroth]

QUOTE(Ami @ Mar 4 2007, 08:07 AM)

Hi,

Can anyone please explain to me what are the benefits of "Inlining" a LabVIEW project (I say project because I mean a very big system developed in LabVIEW). I understand from previous posts that it decreases execution time, but does it have any effect on Projects that are being run as a stand alone executable? Because, I would assume that when an exe file is being built, the compiler already makes the execution as efficient as possible, thus probably using the same techniques that one of them is "inlining".

Thanks,

Ami

Hi,

think of inlining as replacing the subVI call, with the BD of the Sub VI itself.

The benefit by using inlining is that you get rid of the overhead associated with a SubVI call (typically in the us range), e.g. a loop containing special calculations, will benefit by using inlining, since you then remove the overhead in each loop iteration. The higher the loop count the more you gain.

An exe, however, still keeps the subVI hierarchy, and therefore still suffer from this overhead.

If you are using VI-server calls to a VI, then be careful not to break this if you inline your code.

/J

[Chris Davis]

Security is another benefit of inlining. Jim gives a good explanation here.

[Mellroth]

QUOTE(chrisdavis @ Mar 4 2007, 02:22 PM)

Security is another benefit of inlining. Jim gives a good explanation http://thinkinging.com/2007/02/03/security-at-the-subvi-boundary/' target="_blank">here.

Good point, I forgot about that :thumbup:

/J

[dannyt]

Hi

Can I make sure I am not missing the point in all this.

If I understand this correctly the term "In-lining" is NOT failing to splitting your project into sub-vi's and thus abandon your project organisation and good partitioning of code for readability and understanding, but is instead a term for merging your project into one huge Vi at build time to a) improve the programs efficiency and b) significantly improve its security.

If you did do this I assume using the remote debug facility would be next to impossible on your one huge VI.

How much of an issue do people see this two issue of efficiency and security just as a matter of interest ?

Finally if instead of releasing an executable you release the actual project, I suspect this would not be the way to go.

cheers

Dannyt

[crelf]

QUOTE(dannyt @ Mar 5 2007, 07:00 PM)

If I understand this correctly the term "In-lining" is NOT failing to splitting your project into sub-vi's...

Right.

[Ami]

QUOTE(JFM @ Mar 4 2007, 03:06 AM)

If you are using VI-server calls to a VI, then be careful not to break this if you inline your code.

Hi Again,

Can you elaborate more on this issue? Why would the Inlining break these VI-server calls (Do you mean calling VIs by reference?)

Thanks,

Ami

[Yair]

QUOTE(Ami @ Mar 5 2007, 11:49 PM)

Why would the Inlining break these VI-server calls (Do you mean calling VIs by reference?)

I haven't tried using the Inline method, but basically, it takes the code from all the subVI, and puts it directly in the calling VI.

If you then try to call the subVI dynamically (by reference) it will fail because the subVI no longer exists.

[Rolf Kalbermatter]

QUOTE(dannyt @ Mar 5 2007, 04:00 AM)

Hi

Can I make sure I am not missing the point in all this.

If I understand this correctly the term "In-lining" is NOT failing to splitting your project into sub-vi's and thus abandon your project organisation and good partitioning of code for readability and understanding, but is instead a term for merging your project into one huge Vi at build time to a) improve the programs efficiency and b) significantly improve its security.

If you did do this I assume using the remote debug facility would be next to impossible on your one huge VI.

How much of an issue do people see this two issue of efficiency and security just as a matter of interest ?

I personally feal these two issues are non-issues. If you distribute your program as an executable the source code is gone anyhow. So the additional security of not having the VI names as strings appear in the executable is really a minor thing. You can get the same by name mangling your VI names when building your executable.

Performance is for all of my applications not in the subVI call overhead (most projects I develop or maintain currently have between 600 and 1000 VIs) but in the limited user reaction :-) or the limited reaction time of the external hardware systems I need to control. Also when I do calculations I do make sure to use inplaceness and preallocated arrays as much as possible together with shift registers and auto indexing. All these things allowed me to get performances for almost any algorithme, that was close to what you could get with normal C code without dirty optimization tricks and often is faster than many C routines I did find on the net to do the same (and obviously could be optimized by cleaning them up and use more proper functions or implementations).

QUOTE

Finally if instead of releasing an executable you release the actual project, I suspect this would not be the way to go.

Obviously not. Because in the project you distribute the original source code, so at least the security concern would not play at all.

Rolf Kalbermatter

[Aristos Queue]

QUOTE(Ami @ Mar 4 2007, 02:07 AM)

Can anyone please explain to me what are the benefits of "Inlining" a LabVIEW project (I say project because I mean a very big system developed in LabVIEW). I understand from previous posts that it decreases execution time, but does it have any effect on Projects that are being run as a stand alone executable? Because, I would assume that when an exe file is being built, the compiler already makes the execution as efficient as possible, thus probably using the same techniques that one of them is "inlining".

The built EXE does not apply any optimizations that are not applied in the development environment. There are pluses and minuses to this approach. The minus, of course, is that seemingly obvious optimizations -- such as inlining -- are not performed in the one context where it seems they could be safely applied. The plus is that the code you debug on and the code you eventually release are identical, thus dodging one of the major headaches of development in other programming languages.

Inlining is actually a bad example to use since the compiler really has a hard time recognizing that any given VI can be inlined. There are some big reasons:

1) The VI is the fundamental unit of serialization. If there are two calls to the same non-reentrant subVI, then those two calls will execute serially, guaranteeing protected sections of the code. If the VI is reentrant, then inlining pretty much doesn't buy you anything since the caller already has its own instance of the subVI to access.

2) Inlining a subVI could change the preferred execution thread of the caller VI. A VI that has components -- most commonly VI Server property/invoke nodes -- that require the UI thread will generally try to upgrade its entire diagram to run in the UI thread. But maybe you have a rarely used case and generally you want to avoid the UI thread. You can drop the property/invoke nodes into a subVI so that the caller VI stays out of the UI thread generally. Since that might be the only call to that subVI, it would look like a prime candidate for inlining, and undo the whole reason for using the subVI.

3) Since any VI can be dynamically referenced at any time in your code -- without a hardcoded path to that VI necessarily being present anywhere in the code -- the compiler doing inlining could conceivably break code.

Could we add features to LV such that a user could mark a VI explicitly as inlined or explicitly not inlined (which direction would be the best default could be something of a debate). But then you get into issues of having to make non-programmers aware of the implications of choosing that setting, something that LV tries to avoid. And it's not often that inlining would buy you any performance improvement. Yes, there are many cases where inlining a VI will save substantially on memory and/or performance. But these are not the common case. Calling a subVI is a very efficient operation with overhead measured in microseconds. If you happen to find one of those uncommon cases, you can manually inline the code (I know -- not good practice to copy code, and a maintenance nightmare, but it can be done).

If you're having performance issues, there are other places I would look first before inlining any subVI.