Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actor framework slow in development environment

Hi all,

I have a program with multiple actors, some of them in PPLs. When in the development environment, it is slow, especially after running it a few times. When compiled, it works very fast. Is this expected behaviour or is there something I'm not handling/closing properly?

So far I saw (using tick count VIs) that sending a message in one place takes a few ms, but a little further in the same VI sending the same message takes ~800 ms (the act of sending the message, not handling it). Is there a way to debug this? Or to just leave it as when compiled everything is fine?

Thanks,

Danielle

"Wisdom comes from experience. Experience is often a result of lack of wisdom.”
― Terry Pratchett
0 Kudos
Message 1 of 8
(4,975 Views)

I've got about nine actors that I launch, two of them on timed loops (1 sec and 250ms). I haven't done a build yet so all my running is in development mode. While I have other problems, I've noticed no slow down in my project but then again the volume of messages is small (4 messages/sec).

Message 2 of 8
(3,670 Views)

Once the project has an appreciable number of classes the IDE (integrated development environment) will slow down. This is related to the number of classes loaded and the number of methods in each class. My understanding is that a few classes with a large number of methods per class is OK, and many classes with only a few methods per class is OK. The problem arises when you have a large number of classes with vaying numbers of methods.

There are other things that can slow down the IDE too. lvlibs are on that list. I am aware of "some" of the things that have been impicated in the slow down, but I don't know that a public list exists or if there are magnitudes assigned to the slowing due to each type.

AF tends to have a large number of classes, so you can expect some slow down as the project grows.

I know that this is something that NI is aware of and working on.

Casey Lamers


Phoenix, LLC


casey.lamers@phoenixwi.com


CLA, LabVIEW Champion


Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!

0 Kudos
Message 3 of 8
(3,670 Views)

Casey: dsavir seems to be describing *run time* slowdowns in the IDE. What you're discussing are editor slowdowns.

dsavir: No, I've not heard of such things. But, honestly, I don't trust your benchmarks.

1. The tick count node has terrible resolution. Use the "High Resolution Relative Seconds.vi" instead for a more accurate count.

2. You've done that? I still don't trust your benchmarks. 🙂 Sending a message requires that the queue not be in use. If there is another actor dequeuing from the queue, the enqueue has to wait until the dequeue is finished. So do your time testing by sending a message to your receiving actor that will tie it up for a long time (say a message whose Do.vi has a "Wait ms" node wired with a 10000 or something so it is out of the way). Then try sending your messages in the caller and see what performance you get.

There may also be other parallel processes getting in the way. I've done some really extreme instrumentation to check the performance of the queue system that the AF uses to make it as streamlined as I can. Unless this is killing the performance of your app overall (i.e. you've traced your hotspot to the Send), I wouldn't worry about it.

Message 4 of 8
(3,670 Views)

Not reading closely... I saw "Slowdown in Project" and I wrote the reply.

Casey Lamers


Phoenix, LLC


casey.lamers@phoenixwi.com


CLA, LabVIEW Champion


Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!

0 Kudos
Message 5 of 8
(3,670 Views)

Thanks AQ, I'll try your suggestion and then I'll leave it unless it becomes worse

"Wisdom comes from experience. Experience is often a result of lack of wisdom.”
― Terry Pratchett
0 Kudos
Message 6 of 8
(3,670 Views)

Danielle,

Just to put my two cents in - I have a project currently running about 10 or 15 actors at a time with web services and lots of messages flying around.  I have not noticed a degradation in performance (although, as Casey points out, the IDE can get quite slow).  I will reiterate what AQ is saying and suggest that a parallele process is hanging things...

Cheers, Matt

0 Kudos
Message 7 of 8
(3,670 Views)

I'm having this problem very severely in LabVIEW 2018.  I launch about 8 instances of an actor which in turn calls a shared clone re-entrant GUI (old school state machine).  In an EXE, they launch in milliseconds.  Sometimes in the development environment they launch in milliseconds.   The vast majority of the time in the development environment they launch in about 10 seconds each, so, roughly 80 seconds.

 

The loop that launches the actors has parallelism turned on, I assumed all the actors being launched in parallel and in turn launching their copies of the GUI would maximize speed but they all seem to show up one at a time over the course of the minute or two.

 

This has been observed across multiple different GUIs, not specific to just one.  I have used probing to determine if there's something specific causing the problem and it jumps all around, for instance, sometimes a property node call to read the front panel state takes 12 seconds to run.  On another launch it might take a milisecond.

 

Any insight?

0 Kudos
Message 8 of 8
(2,023 Views)