LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to reduce project load time?

It's not the hard drive. I have an SSD, and the active time is never above 20%.

 

Is there a performance difference between autopopulated and static folders?

 

 

 

0 Kudos
Message 11 of 16
(2,047 Views)

@D* wrote:

It's not the hard drive. I have an SSD, and the active time is never above 20%.

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. Or it might be that someone on LV R&D came up with some elegant trick to make it quick. I don't know, but there definitely has to *some* work being done to check the autopopulation.

Message 12 of 16
(2,030 Views)

@AristosQueue (NI) wrote:

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


If you want it to load faster:

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.

 

 


Sorry to revive an old thread, but I was struggling with a similar problem, and found one giant improvement: 

 

Turn OFF "Separate compiled code". Contrary to what AristosQueue said, the "separate compiled code" option makes VIs load much more slowly, especially when you have a large class hierarchy. Knowing what I know now, it makes sense that separating compiled code would cause the VIs to load more slowly, because it needs to compile them when they are opened, and this compilation takes a long time with lots of dependent classes. 

 

To open our project and top-level VI was taking nearly 15 minutes when we were using separated compiled code. When we turned this option off, it reduced the total load time to about 1 minute. 

 

Of course, Separating compiled code has its benefits, especially when using source code control. So you'll need to assess the trade-off between load time and the number of dirty dots you are willing to deal with. 

 

Another change that seemed to improve load time was to reduce the number of "dynamic dispatch" methods. When we first created our project, we defaulted to using dynamic dispatch all of the time. But in many cases, dynamic dispatch is not necessary and simply makes the compiler work harder. 

 

Hopefully that saves someone some time. 

0 Kudos
Message 13 of 16
(1,923 Views)

@EWest wrote:
Turn OFF "Separate compiled code". Contrary to what AristosQueue said, the "separate compiled code" option makes VIs load much more slowly, especially when you have a large class hierarchy. Knowing what I know now, it makes sense that separating compiled code would cause the VIs to load more slowly, because it needs to compile them when they are opened, and this compilation takes a long time with lots of dependent classes. 

All compiled code is cached locally, so you would only see a real slowdown after migrating the project to a new machine and open the project for the first time.

Message 14 of 16
(1,916 Views)

@altenbach wrote:

All compiled code is cached locally, so you would only see a real slowdown after migrating the project to a new machine and open the project for the first time.


I agree with you in theory, but in practice my results make the difference painfully obvious. Load time reduced by about 15x.

 

Maybe there is a problem with the way "separate compiled code" works with Labview classes in particular? I've never had slow loading times with non-OOP projects, even if there are lots of VIs. 

 

Labview's own help documentation says that separate compiled code will reduce loading time (http://zone.ni.com/reference/en-XX/help/371361L-01/lvhowto/separate_compiled_code/), but my results show the exact opposite. 

Message 15 of 16
(1,907 Views)

EWest wrote:

I agree with you in theory, but in practice my results make the difference painfully obvious. Load time reduced by about 15x.

 


Your experience contradicts every performance test and stress test that the LV team has performed. It's why the entirety of vi.lib ships as Source Only. And it works for plain VIs and for LV classes. Yes, you have to compile on first load, but that's it.

 

Maybe there's something else unique to your system?

Message 16 of 16
(1,892 Views)