LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to minimize the number of VIs processed during compilation into an EXE with Application Builder?

Highlighted

@crossrulz wrote:

wiebe@CARYA wrote:

If parent classes have factories, they sometimes include their children as constants. So even if you don't load things dynamically, this would (by design) include all children and all child VIs.

 

This could escalate very rapidly! Use a VI, this includes the class, this includes the parent and grandparent, and all those VIs. The (grand) parent might have a factory, this will include all children. All classes used in those children will be included. All parents of those children will be included. And dependent classes in those will be included. All parents will be included. If they have factories... Soon the entire project will be included... 


This is where a plugin architecture with PPLs become invaluable.  I bit of a learning curve, but well worth it.


I see how it would help a bit with 1) keeping things separated if possible and 2) speed of compilation of the main.

 

But does it help with the actual number of VIs that are compiled or shipped with the exe? It seems to me that would be exactly the same. Or worse if each PPL contains dependencies... VIs that are needed are still needed.

 

For my projects I don't really care if LV compiles 6000 VIs. I'll have a cup of tea, and it's done. But my current distribution demands are pretty basic. I simply deliver an executable...

0 Kudos
Message 11 of 14
(92 Views)
Highlighted

wiebe@CARYA wrote:

@crossrulz wrote:

This is where a plugin architecture with PPLs become invaluable.  I bit of a learning curve, but well worth it.


I see how it would help a bit with 1) keeping things separated if possible and 2) speed of compilation of the main.

 

But does it help with the actual number of VIs that are compiled or shipped with the exe? It seems to me that would be exactly the same. Or worse if each PPL contains dependencies... VIs that are needed are still needed.


If each class in the hierarchy is in its own PPL, yes it does help.  Reason being that the PPLs are already compiled and they just have to sit next to the executable (actually, retain relative paths to each other and the executable).  I literally took an executable build from 30 minutes (and often failed) to <1minute (never fails) by doing this.  And each PPL is small, so those builds where really fast.  Yes, this can quickly turn into a pain to maintain for the first round or two, but then you only update the parts you really need to, narrowing down the build process.  And then to extend, I just have to create a new PPL with a new child class and it can just work without needing the rebuild the executable.

Spoiler
I've spent the last 3 years doing this for a Hardware Abstraction Layer along with other libraries I use on nearly every project.

GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Message 12 of 14
(86 Views)
Highlighted

@crossrulz wrote:

wiebe@CARYA wrote:

@crossrulz wrote:

This is where a plugin architecture with PPLs become invaluable.  I bit of a learning curve, but well worth it.


I see how it would help a bit with 1) keeping things separated if possible and 2) speed of compilation of the main.

 

But does it help with the actual number of VIs that are compiled or shipped with the exe? It seems to me that would be exactly the same. Or worse if each PPL contains dependencies... VIs that are needed are still needed.


If each class in the hierarchy is in its own PPL, yes it does help.  Reason being that the PPLs are already compiled and they just have to sit next to the executable (actually, retain relative paths to each other and the executable).  I literally took an executable build from 30 minutes (and often failed) to <1minute (never fails) by doing this.  And each PPL is small, so those builds where really fast.  Yes, this can quickly turn into a pain to maintain for the first round or two, but then you only update the parts you really need to, narrowing down the build process.  And then to extend, I just have to create a new PPL with a new child class and it can just work without needing the rebuild the executable.

Spoiler
I've spent the last 3 years doing this for a Hardware Abstraction Layer along with other libraries I use on nearly every project.

I'm still doubtful for my situation. I think my compile takes 'only' 10-15 minutes (~3000 VIs in ~400 classes in ~90 hierarchies). But putting the low hanging fruits in PPL won't help that much, and the rest would probably be a lot of work.

 

Also, I only distribute executables at the end of a development period, and then usually 1-5 times at most. So the time it takes is limited to 'every now and then'.

 

If you could PPL a class or class hierarchy, I'd probably have done it already. To me, a lvlib doesn't work well with auto populating folders, but this could be totally irrelevant.

0 Kudos
Message 13 of 14
(74 Views)
Highlighted

@ijustlovemath wrote:

I'm not referring to the "Dependencies" project item, talking more generally about dependencies here. What's happening right now is that no matter what VIs are actually called, the build "processes" every single VI in the project, even ones entirely unrelated to the code that's being built.


Based on this post and the other posts in this thread (before the move to PPL discussion, which I'd also suggest as a good general plan but it does require some investment to set up), it sounds a bit like you have a project file (lvproj, not a project library, lvlib) that contains lots of code that isn't part of the output exe.

 

I'd guess therefore that perhaps you have a whole bunch of Application Build Specifications in your project, and that some code is used for all of them, and some code is specific to one or another build spec?

 

If so, you might find you can build things more quickly by just creating a new lvproj file and adding the files you actually need.

Files can be in more than one lvproj file without any problems (the same is NOT true for lvlibs or lvclasses!*) so this can allow you to load a subset of your total 'project' more quickly, and may in this case also lead to faster builds...

 

Edit: to clarify the statement now marked with a *: What I mean is VIs/CTLs/VIMs etc can only be members of a single class/library. Likewise classes can only be in a single library, or no library. Libraries and classes can still be members of multiple projects.


GCentral
0 Kudos
Message 14 of 14
(41 Views)