Actor Framework Performance Issues

[davidpcl]

Our problems appear to be solved.

I followed AQ's guidance on removing any typedefs from classes and got a small improvement in performance, but what has really made the difference is that I have changed the top level Actor to launch all child actors that contain big toolkits by reference by path which means that when you load the parent into memory it doesn't see any of these child actors.

In this instance what was exacerbating the issues was that because all of the child actors had dependencies on the parent and were reporting data/status' objects back to it, it was then pulling in alot of other child toolkits as dependencies which meant that even opening any of the child actors individually seemed to pull in an awful lot of other stuff.

There is a drawback unfortunately which is that the software now takes an age to fire up because it's having to load all of the child actors and toolkits into memory at runtime but I don't think that's Actors fault, although I have to say that the way Actor strongly couples bits of code together in some instances does slightly concern me, and is possibly my biggest question with regard to whether I am going to continue to use Actor going forward.

Dave

[BrianGShea@NGC]

Davidpci,

This can be mitigated, by loading these depedancies while the splash screen is still up, you can post notifications back the Splash Screen informing the user that module X is loading and so on, or you can just provide a progress bar.

I prefer to be more descriptive just in case one fails to load.

In my main actor's pre load init.vi , i just scan for any LVLIBP in my plugin folder, get the expoted file list and open any lvclass that exists within the library. I hold the array of objects but never use them. Yes, i know this is sloppy but it worked in my quick fix. I'm moving to an object repository whereby any object dynamiclly loaded will be sent to a repositioty that can be accessed by my main app and objects be queried for the default value. Currently i do not do this, i just use get class default value by path.

-Brian

[davidpcl]

A brief update on progress and some more information on my original posting.

Last week was factory acceptance test for this project which we passed without any major issues so our customer now has the ability to fully test a car infotainment system with GPS, FM-RDS, DAB, Zigbee, Bluetooth, CAN, FlexRay and LIN and various other automotive standards.

As with the previous 3 projects I have done using Actor, I have had to ask myself the question of whether I would use it again - the previous answer after the previous projects was absolutely yes as it truly is a remarkable way of developing LabVIEW applications with the key feature of it being in all cases that the software that has been produced has been utterly rock solid and dependable once I'd got the error handler sussed, and the ease with which it is possible to simply tack on a TCP/IP interface without having to make any modifications to the core software cannot be underestimated, and the biggest benefit has simply been that a raft of issues such as the inter process communcation hardly have to be thought about - it's there out of the box.

The problems described in this project have not been entirely down to Actor or LabVIEW classes - we have been using 3 massively resource hungry toolkits in the GPS (this one in particular), FM-RDS and the Maxeye DAB toolkit in one application and the editing has been naeseous at times, but suggestions on this post have helped.

The big revelation though came a few weeks ago when I read a post on here regarding using Abstract classes with Actor, and that has truly sorted all the problems out, and has made it possible to fully decouple much of the software which as well as helping with editing performance, has also meant that we are now building up quite an extensive Actor library, and I would suggest that if you are using Actor or thinking of using it then developing all your Actors to use abstract classes should be top of your priority list.

The other thing that I would highly recommend is to never inherit from Actor Framework directly into a functionally specific module, always inherit into your own base class that your functionally specific classes then inherit from as this has saved us a lot of time and effort in development and also makes the use of Abstract classes alot easier in terms of specifying at runtime the concrete class on the caller to call - you could argue that this is simply good OO design, but it was definitely something that wasn't obvious when I first started using AF.

Thanks again for everyones help and suggestions with this.

Dave

[FabiolaDelaCueva]

Glad it worked out in the end and thanks for sharing your lessons learned.

Fab

[komorbela]

Hey guys,

I just noticed a a very heavy factor to the LabVIEW IDE beeing slow while editing a project with many Classes:

The "Error list" window! If it's open, all changes to the class's private data and probably some other operations are much slower. I guess it is because during these operations the class gets broken -> it influences many other classes to get broken, and the error list window is tracking these changes in "real time".

I don't know if it was obvious to all, or not too many of us knew it, but I haven't ever read about it, so I thought it is worthwhile to share

Please if someone tries and can confirm or deny what I experienced, post it here.

[Ben_Phillips]

Komorbela, you might have noticed that the same thing happens when you have the dependencies list expanded in the project window, especially if there's a lot of stuff in there.  I've seen as much as a 3x difference in IDE responsiveness with that shown/not shown.

[AristosQueue (NI)]

Also, having the VI Hiearchy window open can absolutely kill your dev environment in a large enough VI hierarchy.

[drjdpowell]

These are things that NI can address, no?  Updating these displays only occasionally rather than after each sub step in the recompile.

[AristosQueue (NI)]

Oh, probably. Is it a priority? Not even close at this time. Ask me why it isn't a priority next August.

> Updating these displays only occasionally rather than after each sub step in the recompile.

We already do this. The problem is how those displays get calculated. It's a poor algorithm and it has to run in the UI thread so that the graph is stable while it is being recalculated. It worked for many decades but isn't scaling as LV is used for larger apps.