Actor Framework Discussions
Looking for IDE Performance Optimization Suggestions
I've been working on a multi-developer AF project (started in LV2018 and converted to LV2019) for the past year and, as its grown in complexity (>7500 VIs with >1250 classes including >125 actors), I've seen significant hits in IDE performance specifically related to opening/loading the project from disk (and my computer is new and has an SSD) and building an EXE (it takes over 100 minutes now and that doesn't even include every component).
To try and improve the build and load times of the project, I've spent a significant amount of time working with all our developers and doing the following:
- Eliminating circular dependencies.
- Breaking up large libraries/classes to further modularize the code components and their associated dependencies.
- Resetting the class mutation history.
While these actions have helped with some things like reducing the time of scripting AF messages, the impact on load/build times has been insignificant. I've tested dynamically launching actors, and while that decreases the build times, it increases the startup time when the EXE runs because it's then loading all the actors when it would have done it during the build in the statically launched scenario. Also, if I want to test and I run the code from the IDE, all the classes end up getting loaded into memory anyway and I'm right back where I started in terms of performance until I close and re-load the project.
In trying to figure out other things that I could do, I came across these older posts:
- https://forums.ni.com/t5/Actor-Framework-Discussions/Actor-Framework-Performance-Issues/m-p/3381476
- https://forums.ni.com/t5/LabVIEW/Typedefs-and-Class-Design/m-p/1274222
They state that using cluster typedefs in class private data will adversely impact performance and we do have lots of typedef clusters in our class private data, but before we potentially take the plunge and change everything, does anyone have any benchmarks or experience with whether this would actually speed things up and by how much? I'd hate to spend a bunch of time having everyone remove typedefs from their private data for it to only have minimal impact. Any other obvious things we could be doing to help? Would simply disconnecting the controls from their typedefs in the class private data be enough or, to see any meaningful performance improvements, would we need to convert all the clusters to classes themselves?
This is perhaps a bit drastic or a shift you don't want, but depending on your use case, have you considered PPLs?
That might allow you to break your code into smaller blocks and reduce individual compile times (although the total will probably be longer) and the benefits to load time are qualitatively noticeable for my much smaller projects.
There are a few threads around discussing building AF into a PPL or PPLs, and I'm happy to write more about it if it might be something you want to explore.
Downsides include
- inability (as far as I can tell) to directly run the same code on FPGA (may or may not be relevant),
- a need to compile in specific order (use a build machine - somewhat annoying to set up but fantastic once running smoothly),
- harder to bugfix in place (actually, I'd say that for me that's an advantage rather than disadvantage, but probably not for everyone),
- can require recompiling rather than just relinking if you want to change relative paths between modules (simple solution, all PPLs in fixed relative locations, simplest solution, everything in the same directory).
They state that using cluster typedefs in class private data will adversely impact performance and we do have lots of typedef clusters in our class private data, but before we potentially take the plunge and change everything, does anyone have any benchmarks or experience with whether this would actually speed things up and by how much?
Will defer to others on a research-based answer, but from the thread, it's implied that typedef clusters lack mutation history and thus changes to these clusters are not handled well by class mutation history. If this is the case, then I think clearing the mutation history would give you a "preview" of how well things could work without typedef'd clusters. Then slowly the bad IDE performance would creep back over time. Since clearing mutation history did not substantially help in your case, I suspect the same would be true of disconnecting typedefs.
But I may have misunderstood the original thread, so definitely interested in hearing from someone who's done actual research.
Thanks for starting this thread, Casey. I've been running into very similar problems myself. I have several of my own questions about coding practices and how it relates to IDE performance. Hopefully some people here can share some insight.
Other things that have unknown impact that I would like to know:
- Is having a ton of methods per class a bad thing, even if each method is performing relatively simple operations?
- Related to the above, is creating private/protected accessor VIs for all private data registers actually a bad "bloat" practice that will degrade IDE performance?
- Is it preferable to have a class with a small number of methods with complex block diagrams versus a class with a large number of methods with simple block diagrams?
- Given the same number of actors, in terms of IDE and build time, is it better to have:
- a completely hierarchical structure (each actor launching the next as a nested actor until all actors are launched)
- an almost completely flat structure (one controller actor launches all other actors)?
- For typical use cases, is having more layers of inheritance worse for build times?
- Given a choice between a large number of simple classes and a small number of complex classes, which is better/worse for performance?
And in general, if there is a compilation of all the "tribal knowledge" about best AF/OOP coding practices for keeping build and IDE performance manageable, I would love to see everything in one place.
@cbutcher wrote:
This is perhaps a bit drastic or a shift you don't want, but depending on your use case, have you considered PPLs?
I'm not opposed to using PPLs, but when I started using AF in 2013, PPLs and AF did not play together nicely - apparently that's changed? From a quick search, I see this thread, but I'm a little unclear how I would go about creating the top-level AF PPL in the first place. Is it as simple as pulling in "Actor Framework.lvlib" into a new project and creating the PPL?
There are a few threads around discussing building AF into a PPL or PPLs, and I'm happy to write more about it if it might be something you want to explore.
Yes, if there are threads out there that cover this in more detail, I'd definitely appreciate the links.
I realized that in my previous testing, I hadn't timed the EXE launch time when after the dynamic actor launching implementation. Testing again, my found that my build time decreased by a build time by a factor of 10! Time for the EXE to launch increased by maybe a factor of 3, but that process is orders of magnitude faster than the builds so I'll take it.
If we end up launching everything dynamically I still feel like PPLs are the best way to do it for reasons related to code protection and ease of distribution, etc. But at least this is a step in the right direction.
However, I'm still curious if anyone has any experience with IDE performance as it relates to typedef clusters vs classes.
@Mike_Le wrote:And in general, if there is a compilation of all the "tribal knowledge" about best AF/OOP coding practices for keeping build and IDE performance manageable, I would love to see everything in one place.
Agreed. As it stands I end up Googling/searching lots of separate topics related to IDE performance in AF projects with mixed results. A central list of best practices would be great. Performance metrics tied to those practices and their trade-offs to help me make judgments about when to use one practice vs another would be unbelievable.
@CaseyM wrote:
Is it as simple as pulling in "Actor Framework.lvlib" into a new project and creating the PPL?
There are a few threads around discussing building AF into a PPL or PPLs, and I'm happy to write more about it if it might be something you want to explore.Yes, if there are threads out there that cover this in more detail, I'd definitely appreciate the links.
I think that PPLs in general and AF support for use as a PPL have both improved over time.
In terms of building an AF PPL, there are a few approaches. One is to simply drag everything into the Actor Framework.lvlib library (some things are not included in the shipping library, like Reply Message, and so on), and then build that. You can probably also include AF_Debug as a nested library in that case if you want (or it may load from vi.lib with some persuasion - I haven't tried).
Another option is to build a pair of libraries (AF, then additional messages) and completely remove the debug code. This is the option I chose and you can possibly see the changes here: My copy of NI's Actor Framework with separate library．
The debug library can be difficult because it introduces a circular dependency between the Time-delayed Send Message, Actor Framework, and AF_Debug. Moving Time delayed into AF probably solves this? (then you update the debug library to depend on your new Actor Framework.lvlibp).
