Two Simple Fixes For Build Time and IDE Responsiveness in Large LabVIEW Projects

I was in a meeting recently with a client and one of their clients. Their client was expressing that they were having issues with IDE responsiveness and build times. Their project was a legacy project that had a lot of classes (it was Actor Framework based). I gave them 2 tips. At the next meeting, they noted that they had seen huge improvements just from those 2 tips. I thought I'd share those tips here.

Move Typedefs out of Classes

This tip originally came from Steve Watts. I similarly had a large AF project with the same complaints. Steve suggested this, and it immediately solved my problems.

Why does it work?

Because my issue was circular dependencies. I had typedefs that were part of my actors that were being used by other actors. Somewhere in there, I was not careful and had created some circular dependencies. Simply moving the typedefs out of the classes removed the circular dependencies.

Caveats

You do have to be careful with this one because the class does provide namespacing. If you have a bunch of classes and each has a typedef config cluster, when you move them out of the class, you now have multiple config.ctl files. So, do be careful about that. Maybe rename each first - careful to have all callers in memory - appending the name of the class to the typedef, and then move them out of the class.

Clear Class Mutation History

The second tip I gave them was to clear the class mutation history. There are several ways to do this. You can Google them. An easy way is to just run my Blue Formatter on your code. It will remove the mutation history. Of course, it will also do other things to your code. It is open source, so you can clone the repo and just grab the "remove mutation history" chunk -it's in its own class - and use that by itself.

Why does it work?

Class Mutation history accumulates over time. Every time you change the private data, you get another entry. If you have an old legacy project, that can amount to a large amount of data. It bloats your class size and causes it to take a while to load. If you have a lot of old classes in your project that have evolved over time and that history has never been cleared, this can be a big hit to performance.

Caveats

You do need to be careful with this. Generally, you don't need the class mutation history. However, there are some cases where you do. If you are ever saving an object directly to disk or flattening an object for whatever reason (like sending it over a network, storing it in a database, or on disk, etc) and then later unflattening it, you will likely need to keep it around, but just for that class. The class mutation history for all your other classes can safely be discarded.

More Tips

If you want more simple tips, you should see Allen's GDevCon N.A. video. It covers those tips and some others.

Need Help?

If you have a large legacy project that has gotten out of hand, we can help. This is just one of many tricks and tools that we have for wrangling legacy code. Use the button below to reach out.