Darren's Occasional Nugget 06/12/2023

[Darren]

As LabVIEW continues to be used to create complex applications, programmers continue to look for ways to reduce the amount of time it takes to build their EXEs. I am aware of three changes you can make to attempt to speed up EXE builds... one requires spending money on hardware, one requires spending money on dev time, and one requires spending *lots of* money on dev time.

#1: Faster (single) processor speed

As of LabVIEW 2023 Q1 (the current release at the time of this posting), LabVIEW EXE builds are single-threaded. This means that no matter how many cores your machine has, only one of them will be used for the build. As a result, the processor speed (i.e. the "GHz") is the most important hardware-related factor in building LabVIEW code. Put your code on a machine with more GHz, and in most cases your builds will be faster.

#2: Remove circular dependencies

A VI in First.lvclass calls a VI in Second.lvclass. A VI in Second.lvclass calls a VI in First.lvclass. Assuming one class doesn't inherit from the other, this is an example of a circular dependency. The more circular dependencies you have between libraries (.lvlib and .lvclass), the longer it will take for your code to build. For identifying circular dependencies, I have heard that the LabVIEW Class Dependency Viewer can be useful, although at present, I have not tried it myself.

#3: Break apart the monolithic EXE

If your application consists of a monolithic EXE, consider refactoring your code into a plugin-based system where the EXE is relatively light, and it pulls in dependencies from separately-built and maintained libraries. For example, I've worked with a development team who maintained a massive application (1000s of VIs), but the vast majority of those VIs were built into a few dozen PPLs. The EXE was extremely light and called VIs in those PPLs. When the software is designed in this modular fashion, changes to the code are done to isolated libraries, whose resulting built PPL are a fraction of the size of what the application would be if it were all contained in the same EXE. And in the case of re-building code changes, it's usually one or two of these components that need to be built, not the entire application. Note that if you're starting from a monolith, it's usually going to take a significant amount of refactoring work to make the software more modular. Also note that PPLs can sometimes be problematic to work with.

I've worked with multiple teams of LabVIEW developers who have improved their EXE build times by employing one or more of these methods. 

[Andrey_Dmitriev]

One small lifehack which I using time to time is the fact that we can start multiple instances of LabVIEW (can be done by adding allowmultipleinstances=True into LabVIEW.ini or just by copy LabVIEW.exe -> LabVIEW1.exe and so on).

I have application with PlugIn architecture (around 80 PlugIns, thousands SubVIs), each plugin is own projects with own Build spec, which can be easily invoked programmatically, and simple semi-automated builder, which can build all PlugIns, or just portion. So, in the first instance I can build PlugIns 1...10, then in the second - 11...20 and so on. Everything running parallel without collisions. But full rebuild needed rarely, because during development usually the only few plugins changed, then I don't need to rebuild whole app completely. instead of that the only small portions needs to be rebuilded, this saves huge time for building and deployment.

[crossrulz]

I am a fan of the Solution Builder, which allows me to have all of my libraries in a single project and then the tool builds all of the PPL in their dependent order.  I have only used this for my main HAL framework so far, but it has made life a lot easier.

[justACS]

Removing circular dependencies also usually decreases project load times.  It’s good guidance for all libraries, not just classes.

[wiebe@CARYA]

Removing unused VIs from classes probably helps too.

IIRC, These do end up the exe (not sure why, it would be nice to have a say in it). If you've added a ton of examples or test VIs, it could add up.

Both compile time and exe size will shrink.

[wiebe@CARYA]

Clearing class mutations on all classes also helps project load time, and most likely compile time, and probably exe size too.

Be careful if you depend on serialized (flattened) class data though.

[felipefoz]

---

@Darren  escreveu:

#2: Remove circular dependencies

A VI in First.lvclass calls a VI in Second.lvclass. A VI in Second.lvclass calls a VI in First.lvclass. Assuming one class doesn't inherit from the other, this is an example of a circular dependency. The more circular dependencies you have between libraries (.lvlib and .lvclass), the longer it will take for your code to build. For identifying circular dependencies, I have heard that the LabVIEW Class Dependency Viewer can be useful, although at present, I have not tried it myself.

---

Do you know if this change also impacts project loading time?

[altenbach]

---

@Andrey_Dmitriev wrote:

One small lifehack which I using time to time is the fact that we can start multiple instances of LabVIEW (can be done by adding allowmultipleinstances=True into LabVIEW.ini or just by copy LabVIEW.exe -> LabVIEW1.exe and so on).

---

Very tangentially related and maybe a bug, but even if multiple instances are not allowed, they can happen and it happened to me recently (LV2020). There must be a pinhole leak.

I have a custom built tool in the project menu that not only builds the various specification, but also does some post processing, e.g. , include the lvproj file in the source distribution, modifies the ini of the installer to not ask for "fast startup" changes, and moving all builds to a new folder, etc.

During execution of that tool, LabVIEW sometimes becomes unresponsive for certain moments. If I click in a VI in file explorer during these stalls, they will open in a new instance of LabVIEW. Have not explored in detail, but it surprised me. Oh well...

[crossrulz]

---

@felipefoz wrote:

---

@Darren  escreveu:

#2: Remove circular dependencies

A VI in First.lvclass calls a VI in Second.lvclass. A VI in Second.lvclass calls a VI in First.lvclass. Assuming one class doesn't inherit from the other, this is an example of a circular dependency. The more circular dependencies you have between libraries (.lvlib and .lvclass), the longer it will take for your code to build. For identifying circular dependencies, I have heard that the LabVIEW Class Dependency Viewer can be useful, although at present, I have not tried it myself.

---

Do you know if this change also impacts project loading time?

---

I'm not sure about project load time.  But I do know circular dependencies will hurt IDE responsiveness.  When somebody complains about LabVIEW being slow, it is commonly due to circular dependencies in their code.

[Darren]

---

@felipefoz wrote:

Do you know if this change also impacts project loading time?

---

See the comment from justACS above. Yes, removing circular dependencies will very likely decrease project load time.