Dr. Damien's Development - Improve Load Time with Inlining

[DFGray]

When creating a large application, load time can be an issue.  Users start to get bored after about 10 seconds, and about 15 seconds is a good practical limit.  How do you hit this number?  There are the normal methods:

1. Remove block diagrams and front panels
2. Dynamically load any code you do not need at startup
3. Do a bottom up load of dynamic code in the background so functions not needed immediately will be instantly available when they are needed.  A bottom up, VI by VI load with delays between each load is used to prevent locking the UI interface.  The bottom up approach makes sure you are only loading the VI you think you are and not a lot of dependencies.

To this list, you can also add inlining of subVIs, which can give 50% or more improvement in load time. Most successful large applications are designed using a modular approach.  This can result in a large number of small subVIs.  If the size of the code and data in a subVI is smaller than the subVI calling overhead, the code will be reduced in size if the code is inlined.  This occurs at about 16kBytes.  Large subVIs can be inlined if they are only called once.  More than that increases both the size of the code and the load time.  The load time decreases slowly as the cutoff size is increased from zero, hits a minimum at about 16kBytes, then rises sharply.  Final code size follows a similar pattern.  Unfortunately, inlining is a proprietary VI server function.  The primary reason for this is that it was designed for internal use and has not been properly debugged for general use.  There are also a plethora of conditions needed to successfully inline a VI.

1. The VI must have all control terminals on the main block diagram - nothing inside a structure of any sort.
2. The VI must not depend on the front panel for anything.  For example, VI server methods/properties on front panel objects cause such a dependency.  So do local variables.
3. The VI must not have an event structure.
4. A VI which is part of a LabVIEW Object cannot be inlined into a VI which is not part of the same object. Libraries can cause similar issues.
5. The VI cannot be locked (it can be password protected if the password is in the password cache)

In addition, it is possible to have broken code even if all these conditions are met.  The most common problem is type information created by the front panel controls.  The most common example of this occurs when elements are bundled inside a subVI, then unbundled by name outside the subVI.  When inlined, the names are lost and the unbundle by name fails.  This is easy to fix with a bundle constant in the original subVI supplying the name information.

Attached is a VI and supporting subVIs which will inline the code for a top-level VI.  It checks for all of the above conditions but the LabVIEW Object one (item 4 above), since it is written in LabVIEW 8.0.  It cannot be ported backwards any further, since the internal functionality did not exist before then.  If you use this on code with LabVIEW Objects, enter the subVIs into the exculusion list so they will not be inlined.

Load time improvement will vary, depending on how modular your code is.  The first application I used this on showed a 60% load time improvement.  Typical is probably closer to 40%.  You will also see improvements in disk size.

****WARNING*****

This code may cause crashes and internal errors, since it uses unreleased properties and methods which have not been fully tested.  Use it at your own risk.  Use the exclusion list input to solve errors you cannot solve by modifying the original VIs.  If you try this, please post your experiences and how you solved any issues you ran into.

[altenbach]

Wow, that looks exciting. Now I have something to play with over the weekend. 😄

---

DFGray wrote:

Large subVIs can be inlined if they are only called once. 

---

Sorry, does that mean that small VIs can be inlined also if they are called multiple times? I would think that inlining automatically forces reentrancy, so if we have a tiny functional global for example (action engine!), it probably should be excluded. Do I see that correctly?

You are focusing on load times. How about execution speed? Again I would think that inlining subVIs in a tight loop could speed things up while running.

I am still not fully clear about the usage of these tools. Most likely, things will become clearer once I play around with it. 😄

Here are a few things that came to mind while reading your post:  If I inline a toplevel VI, will it simply updated the code portion inside it so it also contains the inlined sibVI code? Will it also change the diagram itself? Do I need to save afterwards? How do I un-inline a program? If I built an application, do I still need to include the inlined sibVIs? ...

[DFGray]

Inlining a large VI which is only called once will save the overhead of calling the VI in both load and execution.  If the large VI is called twice or more, the savings is lost due to the sheer size of the VI.  For VIs under 16kBytes, every time you inline them, you gain load time and trim application size.

You are correct that inlining forces reentrancy.  Functional globals should be put in your exclusion list.  I don't use functional globals much, so I forgot to include it. Thanks for catching it!

Running the inlining utility will change the code on your top-level VI and probably a lot of other ones as well (the inlining is recursive).  You should copy your code to a new location before using this tool so your original code is not destroyed.  So far as I know, there is no way to un-inline.  The utility saves the VIs in the hierarchy as it traverses through them, so you should not have to save when it finishes.  I could probably change this behavior so a revert would work, but the revert would need to be done on all the subVIs.  I would probably need to write a tool to do a recursive revert.  The final code will be modified with a lot of inlined subVIs.  It is not very pretty and can be difficult to modify (and, unfortunately, debug) since there is a lot of hidden code.  You do not need to include the inlined subVIs in a built application.  I usually use this utility just before building an application.

[altenbach]

---

DFGray wrote:

Inlining Running the inlining utility will change the code on your top-level VI and probably a lot of other ones as well (the inlining is recursive).  You should copy your code to a new location before using this tool so your original code is not destroyed. 

---

Oh, wow! This sounds very dangerous and there should be a big warning dialog somewhere. Is there? Will there be a log of all modified VIs avaliable after running it?

I guess, I will make a development distribution first before touching any of this.

How about vi.lib VIs, do they remain safe?

[DFGray]

The code will not modify vi.lib VIs (although it will inline them if they are small enough).  Before we release anything like this, we will have appropriate warnings or integrate it into the build process, where it can be made safe.  Consider this a highly experimental piece of code.  The warning above was serious.  It could crash LabVIEW and corrupt all your VIs.  Given how much I have used it, this is highly unlikely, but I cannot test it under all circumstances.  This is one of the reasons for the original post.  I would like feedback.

[altenbach]

Great, I'll play with it a bit over the weekend. 🙂

(Instead of the LabVIEW forum, it might have been better to post this in the experimental forum with a brief link in the LabVIEW forum, pointing to it. (or even as a labs item).

Maybe Laura can move ithe thread if desired)

The big warning in the first post does not really say that it will mutilate existing VIs and the need for backups before doing anything It should be more explicit. 🙂

Message Edited by altenbach on 12-12-2008 12:54 PM

[Tomi_Maila]

Damien, thanks for the tool! It looks great!

Maybe it could be possible to create some code inspection utility that would check if the code will actually inline without errors before the inlining is actually executed. 

Are there any means of adding a custom post build step to Source Distribution build that would then call custom utility VI that would inline code after source distribution has been built?

[DFGray]

***WARNING***

Use of the above utility will modify your code.  There is no way to get back to the original code.  Make a copy before you experiment.

[DFGray]

I thought about an inspection tool, but have not had time to really look at it.  I also keep finding more ways to break code doing inlining - most are still due to the front panel supplying type information.  For example, I had an instance of a VI wrapper on a library call.  The code was small, so got inlined.  But the VI was called as the only element in a WHILE loop with an uninitialized shift register containing the error wire.  When inlined, the type info disappeared and the call library node and shift register had no type.  I am not sure how to detect this type of error, other than explicitly looking for each instance as we find them.  That could end up being very slow.

At the moment, there is no released way to call a custom utility before/during/after a build process.  In the case of inlining, you can do a three stage process - make a source distribution, inline it, make a final distribution/executable (assumes you are stripping block diagrams and front panels).  Unfortunately, this is all manual and requires two build processes.  We are very aware of this issue.

[Wiebe@CARYA]

Damien,

Are there plans to integrate this in LV, and exactly how? Or can we do
suggestions here?

Wouldn't it be a good idea to add a "Inline?" option to the right click
context menu of a subVI?

Regards,

Wiebe.