LabVIEW
The packaged EXE file is very large
With the increase of functions, EXE files become larger and larger, and the startup speed becomes slower. Does anyone know how to break exe files into multiple?
There are already 7067KB.
Most of my programs have resultet in about 7MB for 12 years, so i don't think that's accurate. The Fast File Format can help a lot. I haven't tried using Packed Libraries to compare.
@Yamaeda wrote:
Most of my programs have resultet in about 7MB for 12 years, so i don't think that's accurate. The Fast File Format can help a lot. I haven't tried using Packed Libraries to compare.
Packed Libraries in itself won't make a big difference. They are also using the Fast File Format but are otherwise the same as if the compiled VIs are directly stored in the executable.
Where they can help is if your software only uses certain parts in certain modes of operation and you place those functions inside a packed library. They get then loaded as you dynamically load the top level VI inside them (or the class) and not during startup of the main application.
Now, 7MB for a LabVIEW executable is pretty normal, nothing that would normally cause excessive load times at all. The question here is of course: What do you consider slow startup? Most of my applications startup within a matter of 5 to 10 seconds or so, which some might feel is very long, but which I consider fairly normal.
If it is significantly longer than this for you, you must be doing all kind of extra initialization before showing the front panel.
There is a difference between load time of an application and initialization time. And there is of course always the possibility that your application might call into an external .Net driver that first will load and initialize the complete .Net environment before letting LabVIEW do its other work.
I am a fan of using PPLs and a plugin architecture. It is a bit of a pain to get set up, but they are worth it. It greatly helps the update process as each of the files is fairly small and the builds for each is very quick. But that likely won't help your load/startup time.
@rolfk wrote:
Where they can help is if your software only uses certain parts in certain modes of operation and you place those functions inside a packed library. They get then loaded as you dynamically load the top level VI inside them (or the class) and not during startup of the main application.
That was my theory, that having code in PPLs should increase start time (but slow down first execution time as it'll load them then), but i haven't tried it yet. 🙂
@Yamaeda wrote:
That was my theory, that having code in PPLs should increase start time (but slow down first execution time as it'll load them then), but i haven't tried it yet. 🙂
Yes but only if you load the VIs in those PPLs dynamically. This can either happen by loading a class inside the PPL by path (with Get Class Default Value.vi) or by loading one (or several) top level VIs inside it through VI server. If you just plop down a VI from the PPL in your main program, LabVIEW will need to load that PPL at load time as well, and you bought yourself nothing in terms of performance change by using PPLs.
@hy12369 wrote:
With the increase of functions, EXE files become larger and larger, and the startup speed becomes slower. ...
There are already 7067KB.
7MB is NOT large (LabVIEW itself is ~50MB!!) and if your startup speed becomes slow, that probably has a different, more logical reason. How do you measure startup time? How slow is "slower"? (Seconds? Minutes? Hours?). What does the program do, especially when it starts up? (e.g. load huge configuration files, spinning greedy loops waiting for user input, allocate gigantic arrays? hammering property nodes, etc.). What else is running on the computer? Are you short on RAM and other resources? Is the HD OK? (Conventional or SSD?).
Does the program rely on external resources (instruments, DAQ hardware, third party DLLs, etc.)
@hy12369 wrote:
Does anyone know how to break exe files into multiple?
(You make little sense. Breaking anything into multiple parts will slow down the overall combined time, right).
Just to add another 'forgotten' option... It's cheap to try.
If you Right Click a VI, it won't load when the application start.
This can reduce the time it takes to get the application started, esp. when you use this feature on large dialogs that won't do anything until the user clicks an option.
Of course, now it will take more time when the user triggers the dialog.
As a bonus, this option prevents modal dialogs to block when opened accidentally during while the main is running. You can even edit (during development) the VI even if the main is running.
Only caveat is that setting this option prevents Find All Instances to find the VI (Find Callers does). So, add it in a disabled case:
Search LabVIEW like a graph! 