Looking for IDE Performance Optimization Suggestions

[paul.r]

In my experience, circular dependencies are the number 1 thing that slows down the IDE. Aside from the actor framework/actor framework debug library circular dependency, are you sure you don't have any others?

[CaseyM]

---

@paul.r wrote:

In my experience, circular dependencies are the number 1 thing that slows down the IDE. Aside from the actor framework/actor framework debug library circular dependency, are you sure you don't have any others?

---

Pretty sure, yes. I individually added classes and actors to an empty project and monitored their dependencies as I did so. (Side note: It seems like we're sorely missing tools as a community to make this process easier or more automated.)

And again, after doing this, some aspects of development in the IDE did show marked improvements, but not build and load times.

[nath05]

Hi Mike,

I have been talking with Chris and we agreed on sharing some information of what we have found out until now in this forum as well.

I'll continue checking into this with our R&D department and when we get a solid answer I will create an article covering these inquiries so that everybody can access it for future references.

So far this is the information that we have:

Build Time: Building any code into PPLs usually does a good job reducing overall build time. During the build process, LabVIEW will create a new application instance and have to load/compile VIs into this application instance which can take quite a while. If a library is instead built into a PPL, LabVIEW will only have to copy that PPL which is much quicker. Matthias Baudot has a good presentation which covers this (https://www.studiobods.com/en/niweek2018-ts1043/) and in his simple test case he shows that lvlibs can take 12x longer to build than lvlibps.

Now you might say that you will still have to build the PPLs individually which increases the total build time. This is true but you generally only have to rebuild PPLs if your code changes so you not rebuilding many of these PPLs for each release/update.

Project Load Time: When you open a project it will need to load everything in the project and all of its dependencies. This means to get the project to load faster you just need to load less things (easier said than done).

If you are just worried about editing experience, you can get pretty far by just not working out of your master project (I'm assuming there is one big project with every dependency in it). As an example, let's say that you have a project where the top-level VI is some controller that uses VIs from a logging library, a UI library, and a DAQ library. If you need to fix a bug in how your data is logged you don't need to work out of the entire project, just work out of the specific module.

At some point, you may still have to open up your main project. Here, you can still reduce load times by moving to a more plug-in architecture which will only statically load some lightweight interface and dynamically loads concrete classes (https://www.youtube.com/watch?v=XEHPBRmDa7M).

EXE Startup Time: In the end, I wouldn't expect the above changes to really affect total exe load times for better or worse. Dynamically loading plugins will let the main exe startup faster but you will (presumably) need to load in all of your plugins at some point. Now, this may not be relevant to your application but some applications can get away with loading plugins bit by bit. LabVIEW, for instance, has an option to change when palettes are loaded. By default, it will load when needed so you may notice that when you launch LabVIEW and then open up Quick Drop for the first time, it takes a long time to open. You can change this behavior so palettes load during launch which will let quick drop come up very quickly but at the expense of waiting longer at the LabVIEW splash screen.

Even if you are not able to delay loading of your plugins, this does let you add a useful progress bar to your application startup which can make it seem to the user that things are progressing faster (https://99percentinvisible.org/episode/wait-wait-tell-me/).

I hope this information is somehow helpful for you.

Regards,

Natalia Cubillo

National Instruments

[Mike_Le]

Thanks for the interim update, Natalia.

Just a heads up that I've had a lot of trouble converting Actor Framework over to a PPL. If you could include my thread on those problems in your discussions with R&D, that would be helpful.

https://forums.ni.com/t5/Actor-Framework-Discussions/Problems-converting-Actor-Framework-to-PPL-in-m...

Thanks.

[CaseyLamers1]

Casey,

My understanding is that load time and build time both go something like x^2 where x is the number of VIs. So, I spent a good amount of time figuring out how to reduce the number of VIs that my project needed.

To that and, I found a huge benefit from reducing the number of messages that my system used. I did this by having my messages send a class and then using child classes as the payload. In this manner I can have a single "Change Setpoint" message and send a setpoint class. You have to do some additional work to cast back to more specific classes when you do this, but I have found that more tolerable.

Previously I found that a large percentage of my project size was due to message classes.

My build time for a larger project (no PPLs) might still be 40 minutes. This project is about the size of a project that would take 2.5 hours to build before reducing my message class number.

[CaseyM]

Thanks, Casey. Over 900 of the classes in my project are indeed message classes. I'll definitely look into this as a possible reason for the IDE slowdown I've been experiencing.

[Mike_Le]

---

I found a huge benefit from reducing the number of messages that my system used. I did this by having my messages send a class and then using child classes as the payload. In this manner I can have a single "Change Setpoint" message and send a setpoint class. You have to do some additional work to cast back to more specific classes when you do this, but I have found that more tolerable.

---

This sounds interesting, Casey, but I'm having trouble picturing it. Can you elaborate a little more? In particular, I'm confused as to how this reduces the total number of classes.

Based on this description, I'm imagining a 1:1 mapping between what used to be message classes versus what you refer to as payload child classes. But since that wouldn't reduce the total number of classes, I must be missing something about your solution.