Actor Framework Performance Issues

[davidpcl]

Hi,

This is one of those horrible slightly wooly questions but hoping someone out there might have a nugget that might help me out.

I'm developing an Actor Framework that in itself is not hugely complicated, but makes use of many different and potentially quite weighty toolkits i.e. GPS, CAN, FM-RDS, Modulation, DAB Radio etc.

This is not the first time I've used Actor, and is in fact the 4th project which I've chosen to use Actor on, with the other 3 all being of a similar magnitude of complexity and not having any problems.

In this case, I am having horrendous performance issues with the framework, to the point where making a change to the private data of a particular Actor causes a 5 minute wait before I can do anything else during which (I assume) the framework is being re-compiled, and it's obviously causing me significant productivity issues.

I've tried clearing the mutation history as described here without any significant improvement in performance:

http://digital.ni.com/public.nsf/allkb/F0FC362A73C794BA86257C6700692B0B

has anyone else had similar issues, and if so did you find any solutions?

Also - possibly tied in with this, when I load the project there is a particular .dll that takes between 3 and 5 minutes to load nilvdmt.dll (assume that's Digital Modulation Toolkit).

Thanks,

Dave

[TimBotsM]

Hi Dave,

I had something similar, maybe it's not the solution but it might help. I posted my original problem in the forums here.

My "solution" was to set the "Compiler limit" to 0. (This can be found in Tools->Options->Environment->Compiler (at the bottom)). Although I'm still not sure about the total impact of this change the CPU spikes where gone. The "Compiled Code Complexity" (VI properties -> Memory usage) for that VI was with about 2.5 (or even lower) still low.

Maybe someone from NI can tell about the risks of changing this setting but it's easy to revert and could help a lot in the system speed. Also the setting is (as far as I can tell) on a "per project" base.

Let us know the result.

[davidpcl]

Sadly I've already done that and it hasn't helped, the other thing I've tried is to take my classes out of .lvlibs - again, no joy.

Thanks for your response.

[testingHotAir]

I've been having similar issues with my project, though not quite as extreme as a 5 minute delay.  1 or 2 minutes though.

[FabiolaDelaCueva]

Hi Dave,

Have you checked if you have any circular dependencies? I have had problems like this when Class A has a method that is calling a Class B method and in turn Class B has a different method that is calling a Class A method. Sometimes IDE performance is improved by removing this dependencies, this might require creating a Class C that holds the common code to both Classes.

Hope that helps.

Regards,

Fab

[davidpcl]

Hi Fab,

Yes - that has been one of my worries, and one of the first things I looked at but haven't found anything, and with Actor because you are calling messages where the do method is more than likely calling a method from another class it becomes a bit difficult to un-pick what is correct, and what could be a potential issues - and bear in mind that at last count I had 152 classes - most of them obviously messages!

Need a tool really to try and identify any if they exist - something I will try and work on if one doesn't already exist!

Thanks for your reply.

[CaseyLamers1]

I have experienced several things that cause slow downs when building large AF projects and I have a few suggestions.

1. Work on modular pieces on their own. Having a project that contains everything is slow. You may need to start in a bigger project when working with existing code, but create a new project and add a VI to only pull required dependencies. (I make a test harness to launch a piece I need and add that to a new project, see what gets pulled in)

2. Try to minimize what gets pulled into dependencies.

3. Uninstall the Project Provider if you are not actively making messages. I have noticed a big performance hit when the AF Project Provider is installed.

Casey

[FabiolaDelaCueva]

Casey's point of working on modular pieces would help to find the dependencies. That way it is clear by looking in the dependencies folder who they depend on.

[AristosQueue (NI)]

Davidpcl:

Do you have typedefs of significant complexity? Various people have reported editor performance problems when using deeply nested typedefs and/or typedefs of fairly long enums, particularly when those appear inside their private data controls. R&D has not been able to isolate this behavior well enough to do anything substantive about it (we've reproduced it but not found any "smoking gun" that we could clean up in the code, just lots of little operations that all add up), though we have made incremental progress on the problem.

If this is your situation, one thing that customers tell us helps (but which we have not been able to verify) is to not make the typedefs members of the classes. You can use the typedef in the private data of a class or in its VIs, but do not make it a class member. Personally, I have my doubts about this actually helping, but customers say it does, so it may be worth trying.

-- AQ

[davidpcl]

Hi AQ,

I am going to try your suggestion now as I do have a fair amount of typedefs in classes - just the way I've always done it, so be interested to see if it makes a difference.

Thanks for response,

Dave