Loading XXX into memory causes XXX to be loaded into memory

[Desruelle_luc]

Quelques règles sur les problèmatiques de temps de chargement des projets. Le texte est une compilation d'informations internet (Pas de moi.)

Some rules to reduce project load time. This text is a blog posts compilation. (i'm not the author). Links at the end (LAVA or NI website).

I] LV project... and VI in memory

http://forums.ni.com/t5/LabVIEW/How-to-reduce-project-load-time/td-p/936487

The project is a list of the files that you included and their locations :

1. VIs that are listed by the project are not loaded into memory.
2. All library files listed in the project are full loaded into memory when the project loads. But...
   • LVClasses and XControls are both types of libraries. These two types will load all of their member VIs into memory whenever they themselves are loaded into memory.Therefore...
   • A project which loads classes or XControls will -- indirectly -- load all the VIs of those classes or XControls into memory.

3. Any VI that is loaded will load all of its subVIs, whether the subVIs are explicitly listed in the project or not.

II] Loading XXX into memory causes XXX to be loaded into memory or not!

• Loading a vi into memory also causes all (statically) dependent vis to be loaded into memory as well (par exemple le VI Tree). SubVIs are not automatically loaded into memory until the top-level VI is called.
• Loading a library member (*.vi, *.ctl, etc.) always causes the owning library file (*.lvlib, *.lvclass, etc) to be loaded into memory.
• Loading a class file (*.lvclass) into memory causes all class members (*.vi, *.ctl, etc.) to be loaded into memory.
• Loading a project library file (*.lvlib) does not cause all library members (*.vi, *.ctl, etc.) to be loaded into memory.
• Loading a library file (*.lvlib, *.lvclass, etc.) also causes all sub library files (*.lvlib, *.lvclass, etc.) to be loaded as well.

III] To improve the performance

Put all your VIs and classes into a .llb file

To improve the performance (about LV R&D, Aristos Queue) : Put all your VIs and classes into a .llb file. The .llb optimizes the contents of the file and significantly improves load speed when a block of VIs must load as one.

https://lavag.org/topic/14174-extremely-long-load-time-with-lvoop-supanels-and-vi-templates/

The .lvlib is likely having minimal impact on your project load time. The expense is generally from the large number of dependencies that your main VI has.

Move your files to an inner sector of your hard disk.

No, I'm not joking. We have found that hard drives these days are so wide in diameter that location on disk has a massive impact on seek times. Of course, this isn't generally under user control.

Get a solid state drive : SSD

Blazing fast load speeds regardless of what you're working on. Gets rid of the diameter of disk issue.

Save VIs inside .llbs.

The single biggest hit during load is disk seek time, and LLBs solve that by making one file, one file which is optimized for loading the parts of a VI hierarchy. This only helps if you are actually using most or all of the VIs in that LLB.

Turn on "Separate compiled code from source file"

Turn on "Separate compiled code from source file" on all your member VIs and libraries. Makes the VIs you are loading much smaller because the code segment is now in a separate database.

IV] LV project : Is there a performance difference between autopopulated and static folders?

I assume so. I consider autopopulate folders to be way more trouble than they are worth, so I never use them. But every time the project loads it would have to scan the entire directory and rebuild instead of just reading the file, and then any items that are in libraries have to be moved from their place in the autopopulate directory to their place in the library. That could be a lot of work.

website links

LabVIEW Object-Oriented Programming: The Decisions Behind the Design

http://www.ni.com/white-paper/3574/en/

http://forums.ni.com/t5/LabVIEW/How-to-reduce-project-load-time/td-p/936487