Extreme build times for Actor-based application?

[Nate@UT]

Background:  I recently "Actor-ized" a small program which was previously based on a QMH and had some minimal OOP-based design.  Once I gained an understanding the AF's features and benefits, it was a no-brainer to refactor, and my code now has a couple dozen AF-based classes with at most a couple levels of inheritance.  Everything in the project works great running it from the dev environment (LV 2023 x64, Windows 10) and I love the simplicity & extensibility of the new program architecture.

Problem:  When building it into an .exe, the Build Status modal just sits on "Initializing build. This could take several minutes..." for many many many many minutes... like ~20 minutes... before it eventually completes successfully (running through the usual Processing... and Compiling... and Saving... steps in a more reasonable time with progress bar marching as expected).  Prior to my AF refactoring, a build took less ~30 seconds to complete.  There are no Warnings.

So here is my question:  are super long build times something which is a known disadvantage with AF (or LVOOP more generally)?  If not (and my situation is pathological), can anyone recommend any diagnostics tools which I can employ to help tease out what is causing the "Initializing build." step to take so long?  I turned on the _log.txt generation option but that file provides no clues.  (I like coffee but grabbing a new cup every time I have to wait around for a rebuild is probably bad for me.)

[OneOfTheDans]

This has been my experience as well, although 20m seems way too long for that size project. My opinion is that LabVIEW struggles to build/link large quantities of files that are called indirectly (like inherited classes). Unfortunately, the AF uses a ton of tiny boilerplate files (message classes, builders, and Do.vi), which bogs down the Application Builder.

The solution is probably along the lines of using more interfaces more intentionally, so that each Actor stands alone and touches the bare minimum rest of your other Actors.

[justACS]

---

@OneOfTheDans wrote:

My opinion is that LabVIEW struggles to build/link large quantities of files that are called indirectly (like inherited classes). Unfortunately, the AF uses a ton of tiny boilerplate files (message classes, builders, and Do.vi), which bogs down the Application Builder.

---

Not quite right.  We do experience longer build times with class-based applications (not just AF), but it is NOT due to inheritance.  Rather, it has to do with long dependency chains, where you load a VI in a class, which loads the class, which links to (and thus loads) other classes in a library, which links to classes in other libraries, and so on.  If you have any circular dependencies between classes or libraries, you will dramatically compound the problem. 

See my presentation, here:  Decoupling in Practice - How Good Software Engineering Can Save Your Sanity 

---

@OneOfTheDans wrote:

The solution is probably along the lines of using more interfaces more intentionally, so that each Actor stands alone and touches the bare minimum rest of your other Actors.

---

This, plus breaking any circular dependencies, is key.  You should be able to put the actor, plus any interfaces and non-actor classes on which it depends, into a project, and have no other actors in dependencies.  It makes a huge difference in project load and application build times, as well as making it MUCH easier to unit test your actors.

Given your build time, I would look for a circular dependency.  However, if you don't find one, be advised that NI Technical support is not concerned about any build time under an hour.  App Builder is not as efficient as it can be, especially when classes are involved.

[BertMcMahan]

So, good news and bad news- the good news is that no, your long build times are not normal. I have what I consider a "large" project with 118 classes in it. I'd estimate maybe 10-20 of them are actors. When I build within the project, it's maybe 2-3 minutes. Building an installer takes a little longer than that. If I use the MGI Solution Explorer to build outside of a project, the times increase since it needs to first load the project before it builds, but it's still not 20 minutes.

The bad news is that, unfortunately, I don't have a great way to diagnose your issue. Circular dependencies can really increase build times, so maybe dig around and see if you can find some of those (see https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001ECrrCAG&l=en-IL)

You could also switch to using PPL's, but the last time I tried switching to PPL's I wasted a solid two weeks and never could get it to work right. It seems you need to START from PPL's, and that switching over an existing program is a real PITA. (I'm specifically talking about AF here- the problem was that I needed at least 5 levels of PPL's to break out all of the dependencies I had).

I also think OneOfTheDan's point about trying to use interfaces more is a good one. The less each "thing" knows about each other "thing" the better.

[CaseyM]

I echo what's already been said about eliminating circular dependencies and leveraging interfaces.

Out of curiosity, how long did you builds take prior to converting to AF?

[Dhakkan]

Would clearing the LabVIEW cache help? I think I have seen a difference with newer versions of LV (2024) and not necessarily due to AF.

[Nate@UT]

Thank you for the context @OneOfTheDans and @justACS and @BertMcMahan... it's reassuring to know that there is at least some expectation for longer build times when using AF/LVOOP, as well as to know that ~20 mins is unreasonable and that I should expect improvement once I figure out the issue. 

I'm already making use of interfaces and have good separation of classes at the architectural level, so I suspect there is something else in my project that is corrupted or extraneous or otherwise confusing the AB logic. 

I've also occasionally run into the dreaded 1502 errors during build, which from other threads suggest that there is a "bad apple" VI somewhere in my hierarchy.  Perhaps the long build time is related, so I will start fresh .lvproj /.lvlib and reimport all of the source VIs and see if that level of cleanup improves things. 

[Nate@UT · Accepted solution]

Update:  It was a big pain, but I started a new project and then moved all source code over and now it's working normally.  I didn't have to change any dependencies or anything. Seems as if there was just some corruption in one of the project files which was causing the build time issue.

[IlluminatedG]

If you still have the old lvproj file, could be worth looking for odd entries in the dependencies and maybe diffing the two project files, though LabVIEW seems to reorder dependencies at will so that may not be as helpful. I've found corrupted entries in dependencies before (was a problem with a VI shipped with LV) that have caused issues with opening projects and builds.

[BertMcMahan]

Did you ONLY move the source code on disk, or did you move it within LabVIEW? I wonder if you may have cleared out a class's mutation history. I could imagine a long, complicated mutation history could cause some weird linking.