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

I've got an object oriented LabVIEW codebase in LabVIEW 2013, in which I've used a few objects and their methods to create a small testbench VI (data acquisition from a scale).

 

Here's the VI hierarchy:

 

 

The logging functionality (cluster elements to string, seen about 5 levels down on the right) is based on OpenG, but the overall hierarchy is less than 100 VIs, which I would expect to be fairly trivial to compile.

 

However, when I build this target, it processes all 3000 VIs in the project, which seems silly, given there's absolutely no dependencies there.

 

Do I need to factor these objects into their own libraries so that LabVIEW understands this?

0 Kudos
Message 1 of 14
(296 Views)
Highlighted

In your build specification, go to the Additional Exclusions section.  There are two options there you should select:

1. Remove unused polymorphic VI instances - OpenG has a ton of polymorphic VIs and this will remove the instances you don't use.

2. Remove unused members of project libraries - I don't think OpenG uses project libraries, but this is still a good way to weed out unused code in your executable.


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

What about the thousands of other VIs it processes from classes that are definitely not in the VI hierarchy? Do I need to manually exclude all of those?

0 Kudos
Message 3 of 14
(220 Views)
Highlighted

@ijustlovemath wrote:

What about the thousands of other VIs it processes from classes that are definitely not in the VI hierarchy? Do I need to manually exclude all of those?


I *THINK* classes are treated as project libraries in this case.  I will not swear to that though.  But what is calling a class so that it is included in your dependencies?  Those could also be showing up due to other things in your project or something that was dynamically called.


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

There's no dynamic calls in this code; I try to use that very sparingly, usually for async UI code. Also, those settings you mentioned were already set, so I don't think that's the issue.

 

The logging code mentioned is a member of the "Utilities" class I have, which has some general timekeeping, unit conversion, VI server code etc. Many other classes use "Utilities.lvclass" member functions, though I'm not sure why they would be affected just because this class is included in my build.

 

I'll try to factor this logging code into a completely separate library so that it's no longer dependent on this franken-class, perhaps that's the issue.

 

Again, it would be nice to know how the application builder does dependency resolution, because as you saw, the VI hierarchy is really quite small.

0 Kudos
Message 5 of 14
(208 Views)
Highlighted

I Think all that's in dependencies are processed, and if some class has been loaded it'll stay there.

You could recreate the dependencies by removing them from the lvproj file (MAKE A COPY FIRST!) since it's just an XML file.

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 14
(202 Views)
Highlighted

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.

0 Kudos
Message 7 of 14
(195 Views)
Highlighted

So, when the build is finished, these unrelated files are not included? I guess you know about the build preview which will show what files will be included in the build.

 

By "processed/processes", do you mean that their names show up on the build process dialog?


Certified LabVIEW Architect
0 Kudos
Message 8 of 14
(141 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.


But if a VI is in a class, all VI's in the class are included (I think).

 

I know for sure that no VIs in the class can't be broken (which is a bit annoying).

 

If a VI is in a child, all child VIs and parent VIs are probably included.

 

So it could depend on your hierarchy if indeed 'all' VIs are compiled. Do you know for sure all VIs are compiled? Or just a lot?

 

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

0 Kudos
Message 9 of 14
(131 Views)
Highlighted

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.


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