09-17-2013 12:57 PM
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?
09-17-2013 03:20 PM
@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.
05-21-2015 03:28 PM
@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.
05-21-2015 03:36 PM
@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.
05-21-2015 03:41 PM
@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.
05-21-2015 04:10 PM
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?