How to reduce project load time?

[Daklu]

I am currently working on a large project (25+ Mb, thousands of vis) with something on the order of 100 classes.  Opening the project is painfully slow.  It usually takes 7-8 minutes.  I'd like to figure out a way to reduce the load time.

What is LV's behavior regarding loading project file vis and libraries (lvlib, lvclass, etc.)?

1. Are all items in the project automatically loaded when the project is opened?
2. Are items not in the project but used as sub-vis automatically loaded?
3. Are dynamically linked items not included in the project automatically opened?  (I imagine not.)
4. Are dynamically linked items that are included in the project automatically opened?

Thanks,

Dave

[iZACHdx]

Hello,

Have you tried this project on multiple computers with the same result? Also, have you tried creating a new project?

1. The project is basically a list of the files that you included and their locations. These files are thus technically loaded but are not loaded into memory.
2. The subVIs are not automatically loaded into memory until the top-level VI is called. 
3. No.
4. No. The project looks for dynamically linked files that are included in the project by searching specific locations. Again, this should happen when a VI is called from the project.

-Zach

[Daklu]

Thanks for the reply Zach.  The project is routinely loaded on two other computers (two developers and one target computer) and while neither one takes as long as it does on mine, it still takes quite a while.  I haven't tried creating a new project yet, mainly because the project is so large.  (Lots of files to bring in.)  Why would a new project file with the same content reduce long load times?

"These files are thus technically loaded but are not loaded into memory."

LV finds dependent sub VIs that aren't included in the project, so it must load each VI to the point where it can find the sub VIs.  I'm guessing it's more of a load-read-unload process?  (Unless LV maintains a disk-based linked list with references to each VI's sub VIs?) 

Let me rephrase questions 3 and 4.

• If I switch the statically linked classes in the project to dynamic linking and leave them as part of the project file, would you expect the project load time to be reduced?  (Probably not.)
• If I switch the statically linked classes in the project to dynamic linking and remove them from the project file, would you expect the project load time to be reduced?  (I'm guessing yes, but it would be a pain to use those VIs during development.)

[iZACHdx]

Hello,

I have talked to multiple people about your issue and we honestly believe that you you are experiencing is expected behavior based on the size of the project and number of VIs used. Creating a new project will sometimes help when a project file has a corruption within it. Since you are experiencing the same behavior on multiple computers, any difference in load time will be a function of the speed, RAM, etc. of that particular computer as compared to your machine. In saying that the files are technically loaded, I am saying that their locations are known so that when they are called, they can be loaded into memory as needed. It does not have to load any portion of the VI other than the location on disk. I would not expect either of those methods to reduce your project load time. Switching to dynamic linking only changes the order in which LabVIEW searches for the files. As I stated before, files added to the project are defined by the name and location on the disk. You can think of the project file as an XML file with different pieces of information about the files. If the file cannot be found, it will try to dynamically link the files by searching for them on the disk. When this happens, it goes through a seris of locations where the files might be located. When the project is loaded, it looks for the files that are listed in the project file first. I hope this helps.

-Zach

[AristosQueue (NI)]

---

Daklu wrote:

What is LV's behavior regarding loading project file vis and libraries (lvlib, lvclass, etc.)?

1. Are all items in the project automatically loaded when the project is opened?
2. Are items not in the project but used as sub-vis automatically loaded?
3. Are dynamically linked items not included in the project automatically opened?  (I imagine not.)
4. Are dynamically linked items that are included in the project automatically opened?

---

Correction to the earlier reply.

1. All library files listed in the project are full loaded into memory when the project loads. VIs that are listed by the project are not. But...
   1. 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...
   2. A project which loads classes or XControls will -- indirectly -- load all the VIs of those classes or XControls into memory.
2. Any VI that is loaded (see #1) will load all of its subVIs, whether the subVIs are explicitly listed in the project or not.
3. Dynamically loaded items not listed in the project are not loaded into memory.
4. Dynamically loaded items listed in the project will load if they meet the conditions described in #1.

[Daklu]

Thank you both Zach and AQ.  Your responses are helpful in formulating a strategy for future large projects.

FWIW, I discovered the extremely long project load times are due to a faulty device driver causing frequent interrupt storms.  I haven't figured out which driver it is, but I don't believe it is related to LV.

[D*]

Correction to the earlier reply.
All library files listed in the project are full loaded into memory when the project loads.

---

Hmm...Does this mean library files that are listed in the Dependencies will load with the project as well?

My project has 13721 .vis (including Dependencies), and the project takes forever to load.  However the main .vi only has 3102 .vi's.  also takes a long time. 

I have a lot of .vi's in .lvlib that are not being used (i.e. I have an instrument driver .dll that had ~100 functions.  I used the .dll wizard to wrap all of them, but I only need a few right now.  I'd like the ability to use the others in the future)

If I want my project and my main .vi to load faster, what should I do?  Stop using .lvlib?

Thanks,

-D

[Yamaeda]

My experience is to stop using projects (or less atleast), and work on the class files directly. It speeds things up, but you cant and shouldn't avoid the project files completely.

/Y

[AristosQueue (NI)]

---

@D* wrote:

Correction to the earlier reply.
All library files listed in the project are full loaded into memory when the project loads.

---

Hmm...Does this mean library files that are listed in the Dependencies will load with the project as well?

---

[EDIT] I misread your question. Fixing the answer...

Yes. Dependency library files are loaded.

[AristosQueue (NI)]

---

If I want my project and my main .vi to load faster, what should I do?  Stop using .lvlib?

---

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.

If you want it to load faster:

1. 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.

2. Get a solid state drive. Blazing fast load speeds regardless of what you're working on. Gets rid of the diameter of disk issue.

3. 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.

4. 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.

Those are the things that I know about as general solutions. There are obviously project-specific things like making some files be dynamically loaded instead of direct subVI calls (i.e. pop up on a subVI and choose "load when called"), but those have impact on your final application that you may not want.