Do lvlib files pull all their member VIs and dependencies into memory when called?

[Mike Le]

So we're working on untangling dependencies in our projects.

 

In the process, we've removed some member VIs from certain classes. These member VIs were organizationally related to their parent class but didn't actually use the class an input/output. They were sometimes called outside the class, which would load the entire class into memory in the IDE.

 

This was undesirable behavior, so we moved them out.

 

However, now I'm concerned that there are lots of "orphan" VIs floating in our repository that aren't organized in any way. I pitched the idea of throwing them into some lvlibs. For example, we have an application called APT. So if there are "orphan" VIs in APT, we could throw them into a library called "APT Common Code.lvlib" or something like that.

 

My coworker Tom wanted to check some of the "common wisdom" we've heard that lvlibs do not load all their member VIs into memory when a single member is used.

 

I created a dummy project and made a few Actor classes. The application just launches a window with a message saying "Application running." Then it shuts all the Actors down when that window is closed.

 

I created "Dummy Library.lvlib." I put in two member VIs. One is just an empty VI with an error in and error out. I called this "Empty VI.vi".

 

The other is called "APT Container.vi." On its block diagram I dropped one of the core APT VIs, which calls a lot of other VIs.

 

"Dummy Library.lvlib" is not in the lvproj.

 

I then dropped "Empty VI" onto one of the Actor Cores. "Dummy Library" of course shows up as a dependency.

 

So does "APT_Main" and all of its dependencies, resulting in a massive list of dependencies. Project load time also increases from <10 seconds to about 1 minute.

 

Based on this testing, I think I have a fundamental misunderstanding with how lvlib files work. I'd really appreciate any guidance on this topic. In particular:

1. Do lvlib files load all their member VIs into memory?
2. If not, then what am I doing wrong that is causing the member VIs to load into memory? Or what is my misunderstanding with the phrase "load into memory"?
3. If yes, then is there an alternative way to organize these "orphan VIs" so they aren't simply floating in the workspace without any simple way to identify or group them? (while still avoiding loading all of them into memory when I only want a particular one)
   

Thanks all.

[drjdpowell]

Uh oh.  Your right.  I hadn’t appreciated this before. I built a test project and library myself (LabVIEW 2011).  I used the Application properties to find what VIs are actually in memory as opposed to just listed in dependancies.  The unused VIs in a library are NOT actually loaded, but any libraries in dependancies ARE, and if that library is a class, then the contained VIs (and all their dependancies) are loaded.

 

 

Here “Uses Empty VI" is in the project but not loaded.  It uses “Empty VI”, which is in the same library as VI that calls a method of "Cyclic Table” class.  None of the three VIs in the chain are loaded, but the Library and Class are.

 

NI really needs to fix the library system; it’s badly broken.

 

Added later: a useful link.

[Mike Le]

This is probably a stupid question, but how does LabVIEW know what to list in dependencies without actually loading the VI's contents into memory?

 

In your example, "Uses Empty VI" is in memory, which calls Empty VI. Empty VI is in the same library as VI with Dependancy VI Call.

 

Apparently "VI with Dependancy VI Call" is not loaded into memory, but the class it calls ("Cyclic Table") is? So, how does LabVIEW know that Cyclic Table is called without loading "VI with Dependancy VI Call"?

[drjdpowell]

I would guess it opens the file and reads in the dependancy list, without actually loading the code.

[Aristos Queue]

It uses the Read Link Info application method to harvest the linker graph info without loading the files.

 

Most library types do not load their VIs. They do load their nested libraries. Classes and XControls are the only two types of libraries that load their member VIs.

[Tom Fantasia]

Why do .lvlibs load nested .lvlibs into memory?

[Steen Schmidt]

On 15/4/2014 at 3:05 AM, Tom Fantasia said:

Why do .lvlibs load nested .lvlibs into memory?

One reason might be that to read the linker info you'll have to traverse the entire lib tree. Since refnums to all libs in the tree after this are now in memory, they are left in memory. Perhaps under the assumption that stuff within that tree is soon to be called, and thus it's assumed more efficient to leave them in memory than to close them again? The libraries themselves aren't that heavy, but quick access to the linker info will give you a more responsive IDE.

The better question is why do classes have to load all their VIs? XControls have to because they execute, but class execution is runtime only.

[Rolf Kalbermatter]

I would guess that it has to do with dynamic dispatch. Most likely dynamic dispatch would get significantly slower (and I'm talking here more than a few 100 nanoseconds which some people already found an insurmountable problem when NI changed something in the dynamic dispatch code between LabVIEW 2014 and 2015) if there was the possibility that a VI is not already loaded!

[Steen Schmidt]

Yes at runtime. But dynamic dispatch isn't a phenomenon at edit time, only the type resolving (which doesn't have to force load of all VIs in the class). So my question remains; what is the reason behind classes having to load all their member VIs in the editor? Since classes are basically a type, it is probably to avoid edit racing like with typedefs (two people simultaneously editing two members, afterwards both edits need to update the same class lib resulting in a non-resolvable conflict).

Edited December 28, 2016 by Steen Schmidt