What process do you use to strip unneeded VIs from your builds?

[yuwon44]

I've got a big legacy codebase, and building applications that reuse code means big big build times. What confuses me is the inclusion of VIs and entire classes that appear nowhere in the call chain of the Startup VI. There's not even dynamic dispatch used in some of these applications, so it's hard to understand why these inclusions are happening.

How do you slim down your binaries and build times? Refactoring into a bunch of libraries? Avoiding any and all dispatch? Something else?

[billko]

Anything in "Additional Exclusions" useful?

[rolfk]

- Maintaining code sanitation throughout development. 😉

And in the case of code that I inherit or must maintain, generally at least a day or two to understand the interdependencies, clean up the project tree to contain related functions in related virtual folders (and adjust the disk layout accordingly), renaming VIs to a more consistent naming scheme and sometimes even create libraries to namespace related functions in their own "prefix" and make as many of the VIs as possible private.

And if there are classes, make those damn methods that nobody outside the class should have access to, private too, or at least protected. I hate it when one of the stronger reasons to use classes is not used properly or sometimes not at all.

[jcarmody]

I may be missing the point of your question, but...

When I inherit a project and I expect that a lot of the VIs aren't used I'll create a source distribution from the top-level VI and begin a new project from that.  Then I'll learn pretty quickly about dependencies I've missed.

[crossrulz]

---

@yuwon44 wrote:

What confuses me is the inclusion of VIs and entire classes that appear nowhere in the call chain of the Startup VI.

---

That usually points to having large libraries and only using small portions of the code in the libraries.  But when built, the entire library is added into the executable.  Some options:

• There is an option in the build specification to exclude unused code from libraries.  I tend to avoid this, but you could try it.
• Examine the libraries and see if they could be broken down into more succinct libraries (ie, make more smaller libraries).  Make sure the library is more one specific job (ex: data logging).
• Some will balk at this, but use Packed Project Libraries.  Have a project just for building these libraries into PPLs.  When your executable uses these, the libraries will not need to be built with the executable and build times will become a lot faster.  I had a build that went from 10 minutes to 10 seconds after turning my libraries into PPLs.  You do have to be more careful on the process and organization of the code, but they are quite useful.

[crossrulz]

---

@rolfk wrote:

And in the case of code that I inherit or must maintain, generally at least a day or two to understand the interdependencies, clean up the project tree to contain related functions in related virtual folders (and adjust the disk layout accordingly), renaming VIs to a more consistent naming scheme and sometimes even create libraries to namespace related functions in their own "prefix" and make as many of the VIs as possible private.

---

I tend to ask for a week.  Granted, the size of the code base is a factor as well.