LabVIEW 2023 Q3 + builds significantly slower if compiled objects are cleared

[avogadro5]

My organization uses CI workers to build our projects. As part of the build script, the 1st task is to clear the compiled object cache before starting the build. This discussion illustrates why, but it boils down to wanting a repeatable environment, and since the build output can be different with and without a clear cache, always clearing is the only repeatable option. All the LabVIEW code has "separate compiled code" checked.

The problem is, on 2023 Q3, 2024 Q1, and 2024 Q3, (all Windows, 32-bit) the build speeds have been significantly slower than 2021 SP1. If I don't clear compiled objects between builds, they can be the same speed or faster (after the 1st build). Additionally, since there are multiple workers a project might not be built on the same worker consecutively, so we pay the "1st build slower" penalty either way.

I attached a test project I created that generates a comparable build to the kind I'm noticing the slowdown on (lots of small classes, think Actor Framework). I ran some experiments on a VM that was idle other than doing the builds, and found these trends on build times: they're ~66% longer with the same clear->build process in 2024 Q1 as 2021 SP1. If you want to use the test project, 1st run "codegen_classes.vi" then "codegen_vis.vi" then "build.vi."

O(n^2) is concerning regardless...

This trend has replicated across several computers, and in 2023 Q3 and 2024 Q3.

Has anyone else run into this? Is there a way to get the old "non-caching" builds back in the later versions? Am I being overly paranoid about clearing compiled objects?

[Yamaeda]

LV have a build cache now, so it doesn't have to recompile everything for a build. This increased build performance greatly (by lowering the time). By clearing the cache you're forcing a recompile and rebuild of the cache each time.

[avogadro5]

---

@Yamaeda wrote:

LV have a build cache now, so it doesn't have to recompile everything for a build. This increased build performance greatly (by lowering the time). By clearing the cache you're forcing a recompile and rebuild of the cache each time.

---

I'm aware of that. This thread is about why doing so results in a slower build after 2023Q3.

[Hooovahh]

---

@avogadro5 wrote:

---

---

I'm aware of that. This thread is about why doing so results in a slower build after 2023Q3.

---

I'm going to guess it was optimizations NI made.  I remember hearing about improvements in some kind of build process from NI during the betas. Someone mentioned how they weren't interested in the improvements since they also clear the compile cache before builds and that any effort the team was making wouldn't be helpful to them. They were then surprised to hear that developers clear the compile cache for consistent environments, or to avoid build issues (which is why I do it).

So the change to increase the build time was likely an intended decision with the trade off being better builds somehow, if you weren't clearing the cache.

[avogadro5]

---

@Hooovahh wrote:

---

@avogadro5 wrote:

---

---

I'm aware of that. This thread is about why doing so results in a slower build after 2023Q3.

---

I'm going to guess it was optimizations NI made.  I remember hearing about improvements in some kind of build process from NI during the betas. Someone mentioned how they weren't interested in the improvements since they also clear the compile cache before builds and that any effort the team was making wouldn't be helpful to them. They were then surprised to hear that developers clear the compile cache for consistent environments, or to avoid build issues (which is why I do it).

So the change to increase the build time was likely an intended decision with the trade off being better builds somehow, if you weren't clearing the cache.

---

That was probably this discussion I linked. Feedback in the beta appears to have been no interest in the build speed improvement, and only discussion about how people want to clear their compiled object cache. It seems like there was no effort by NI to address why people feel they need to clear the cache, and now we are stuck with slower builds. Which would be rather annoying except we pay for LabVIEW licenses to run these CI jobs, so slower builds translates to more seats needed to accommodate the same load, translates to more money for NI as a reward for not considering our use case.

[avogadro5]

It's also not just if you clear the cache, because the caching appears to be based on file modification date (based on some experiments and also opening the cache with a SQLite browser), which for a CI job that does a git clone before everything else is always ~now.

[avogadro5 · Accepted solution]

I submitted a support request and NI is aware of this at least for the "new timestamps" case.

"aware" != "will do anything" and "aware" != "cares"

[avogadro5]

Unrelated, there's a bug in my test code that caused the build speeds to be O(n^2) on number of classes since the links were not correct so it had to search for the files. So classes aren't a fundamental scaling problem.