Actor Overload!

[AristosQueue (NI)]

I also would use AF for heavy UI work where I had multiple UIs needing to update independently. If I had a single panel with 10 subpanels, each of which is doing its own thing, making each of those panels be the panel of some actor's Actor Core.vi is a no-brainer for me, if only for the ease of controlling the stop behavior! 🙂

And using the AF on RT is fine. Using it on VxWorks is where there's a problem. VxWorks is a subset of RT.

[AristosQueue (NI)]

drjdpowell wrote:

I found similar results with a different dynamic-launch framework, and confirmed them with a more-simple, preallocated-clone subVI test.  The time to allocate clones seems to grow non-linearly with the number of clones, so loading clone number 5001 takes a lot longer than clone 101.

I would be very interested to see your benchmark VIs -- I believe what you say, but there are several different reasons I can think of off the top of my head for this behavior, some of which could be worked around and some of which could not.

[AristosQueue (NI)]

LVB wrote:

How does the AF handle thousands of messages? This was also a concern with a few developers I spoke with at NI Week.

The same way it handles 10s of messages: with grace and style.

Seriously... as is discussed in the whitepaper and the Intro to AF presentation, both the theory and the empiric testing of early adopters say that the AF should scale up just fine to handle high speed message production/consumption even with large burstiness.

LVB wrote:

For UI heavy applications that only need to communicate a few items between modules, I have considered putting a JKI state machine/QMH in the Actor Core and having the actor messages fire user events.  I find the JKI State Machines much for efficient for development.  There is significant time spent creating methods and messages to update the actor from an Event Structure vs adding a case to a QMH case structure.  Any thoughts?

I fully support and applaud putting a state machine (of whatever template) into the Actor Core. I fully support putting an Event Structure into Actor Core. What I wouldn't do is put an Event Structure inside a state machine. If you have state to manage, that goes in a separate actor (inherited ancestor, nested actor or managed sibling, your choice) because that is functionality... keep it isolated from your displays and data entry. Trying to handle UI in the same loop as you're actually doing whatever task it is that you're trying to do is among the management nightmares that the AF tries to address. "Hey, I can't actually process events because the state machine isn't in the state with the event structure!" Well, if you never have such a state, you never have such a hang.

[justACS]

LVB wrote:

I concur that the AF is great for MVC patterns.  However, I fear the scalability of the AF for large complex applications with multiple windows.  How does the AF handle thousands of messages? This was also a concern with a few developers I spoke with at NI Week.

How do systems built from queue-driven message handlers handle thousands of messages?  At the end of the day, QMH's and AF systems are just sending clusters of data over queues.  And AristosQueue maintains that dynamic dispatch is more performant than the case selection/VI call/data unflattening that happens in a QMH.  We won't know for sure until someone does it, but we have seen nothing to date that suggests that AF does not scale at least as well as a QMH system.

For UI heavy applications that only need to communicate a few items between modules, I have considered putting a JKI state machine/QMH in the Actor Core and having the actor messages fire user events.  I find the JKI State Machines much for efficient for development.  There is significant time spent creating methods and messages to update the actor from an Event Structure vs adding a case to a QMH case structure.  Any thoughts?

I don't agree with your basic assertion.  Creating a method takes about the same time as adding a case to a case structure - both contain the same code, after all.  Most messages take seconds to write, courtesy of the Message Maker.  I suppose you could use a JKI state machine to handle passing data from Actor Core to your UI - I use events for that purpose, myself, most of the time.  But JKI's state machine seems a little heavy weight for that.

[LVB]

AristosQueue wrote:

...

What I wouldn't do is put an Event Structure inside a state machine. If you have state to manage, that goes in a separate actor (inherited ancestor, nested actor or managed sibling, your choice) because that is functionality... keep it isolated from your displays and data entry. Trying to handle UI in the same loop as you're actually doing whatever task it is that you're trying to do is among the management nightmares that the AF tries to address. "Hey, I can't actually process events because the state machine isn't in the state with the event structure!" Well, if you never have such a state, you never have such a hang.

I fully understand the limitations of this.  However, I would bet that 90% of LabVIEW programmers put the Event Structure inside the state machine...

I hope we can agree that a QMH or JKI State Machine has it's place.  It is what I suggest to beginner LabVIEW programmers.  As long as you hit the "Idle" case to process events every 200 msec or so...  If there is a case that takes longer, that may be the time to add an actor.  I think it also introduces the concepts of the Actor Framework to beginner users: Data Shift Register = State = LVOOP Class Data, Cases = Methods, Enqueued States = Messages.

This seems like a good "stepping stone" template for developers to move from a QMH to LVOOP/Actor Oriented Design.

[LVB]

niACS wrote:

How do systems built from queue-driven message handlers handle thousands of messages?  At the end of the day, QMH's and AF systems are just sending clusters of data over queues.  And AristosQueue maintains that dynamic dispatch is more performant than the case selection/VI call/data unflattening that happens in a QMH.  We won't know for sure until someone does it, but we have seen nothing to date that suggests that AF does not scale at least as well as a QMH system.

I should probably rephrase my question:  How does the LabVIEW IDE deal with thousands of message classes?  In my past experiences, the IDE slows to a crawl with a large number of classes (> 200).

niACS wrote:

I don't agree with your basic assertion.  Creating a method takes about the same time as adding a case to a case structure - both contain the same code, after all.  Most messages take seconds to write, courtesy of the Message Maker.  I suppose you could use a JKI state machine to handle passing data from Actor Core to your UI - I use events for that purpose, myself, most of the time.  But JKI's state machine seems a little heavy weight for that.

Let's take the example of a simple boolean "state" set from a front panel control.

• JKI State Machine
  • I can drop a Bundle By Name inside an event structure and wire data into the JKI State Machine shift register in about 5 seconds.
• Actor
  • Creating a class method requires creation of a file on disk (10 seconds), an icon (30 seconds), and an associated message class (30 seconds)
  • Moving the message class on disk to the desired location (10 seconds), and then droping the message class into the event structure (10 seconds).

That would add up to 90 seconds compared to 5 seconds.

[Daklu]

AristosQueue wrote:

LVB wrote:

For UI heavy applications that only need to communicate a few items between modules, I have considered putting a JKI state machine/QMH in the Actor Core and having the actor messages fire user events.  I find the JKI State Machines much for efficient for development...  Any thoughts?

I fully support and applaud putting a state machine (of whatever template) into the Actor Core. I fully support putting an Event Structure into Actor Core. What I wouldn't do is put an Event Structure inside a state machine.

The JKI State Machine is a state machine in the same way the QSM is a state machine--by naming tradition only.  It is a "sequencer" (as identified by Justin) and it is not (as characterized by me) well suited for implementing a behavioral state machine.  While I agree I wouldn't put an Event Structure inside a state machine, I also wouldn't use the JKI SM to implement a state machine, so the comment may not be applicable to LVB's intended use case.

If you're using the JKI SM as a pure event handler/UI updater and implementing the working code in other loops, I think you'd be fine.  However, if that's all you're doing the JKI SM seems like overkill.  All you need is an event structure in a while loop.

[Daklu]

I know this response was directed at AQ, but I can't resist a good SM discussion. 

LVB wrote:

However, I would bet that 90% of LabVIEW programmers put the Event Structure inside the state machine...

Then--assuming you are referring to a behavioral state machine rather than a QSM or JKI SM--90% of LabVIEW programmers are doing it wrong, or at least doing it in a way that is adding unnecessary complexity.  (Yep, I said it.  Flame away.    )

LVB wrote:

I hope we can agree that a QMH or JKI State Machine has it's place.

I don't deny they may have their place as lots of people swear by them... I just haven't figured out what it might be.  For any non-trivial application they seem to trade away readability in exchange for the ability to write code quickly.  I'll take readability over coding speed every single time.  Granted, I'm rather more anti-QMH than AQ.  (Or anyone else I know for that matter.)

LVB wrote:

This seems like a good "stepping stone" template for developers to move from a QMH to LVOOP/Actor Oriented Design.

I disagree.  I believe QMH/QSM (and to lesser extent JKI SM) habits actually get in the way of understanding AOD.  One of the rules of AOD is an actor can receive any message at any time and the actor must react appropriately.  QMH designs often depend on messages arriving in exactly the right sequence.  When that sequence is messed up the QMH behavior becomes unpredictable.  This requires the developer to jump through all sorts of hoops to try to ensure correct sequencing and is a prime source of subtle bugs.  (Did you see Norm's presentation at NI Week?)

QMH practices also confound the purpose of messages, states, and sub vis, treating them all as roughly equivalent.  This creates a lot of confusion when trying to introduce more advanced designs, like a behavioral state machine.  We'd all be better off if QSM pratices were eliminated from our collective conscious.

[fabric]

LVB wrote:

I should probably rephrase my question:  How does the LabVIEW IDE deal with thousands of message classes?  In my past experiences, the IDE slows to a crawl with a large number of classes (> 200).

...

I was just going to make the same observation. In my experience to date, AF designs promote good architecture (blah-blah, we all know the benefits), but that comes at a not-so-insignificant price. 

Hundreds of classes are a nightmare for the IDE. When I go to edit my class properties I need to wait at least 10s for anything to happen. (That's on a speedy i7 with bucketloads of RAM, and maybe a hundred classes loaded.) Want to change the default class icon? 10s wait. Want to modify inheritance? 10s wait. Need a better looking wire? 10s wait. Its awful...

Additionally, the inherent "class separation" between actors and their associated messages means that either:

1. Many more accessors are required to access class properties from inside "Do.vi". This forces me to scope a bunch of accessors to be public (or at best community), even if they are exclusively for "private" use of my actor.
2. OR:  I need to wrap all functionality I want to "Do" in a static VI that lives in my actor class, i.e. more framework. This can be daunting for new adopters from the land of state-machines. It increases the ratio of "number of actor-related VIs" to "number of case structure frames" up to at least 3:1.

But I like classes so much that I put up with it. I'm hoping that AF raises the profile of LVOOP enough that thousands of others get frustrated too and the blue lords spend some serious effort on optimising the whole experience.

[drjdpowell]

AristosQueue wrote:

drjdpowell wrote:

I found similar results with a different dynamic-launch framework, and confirmed them with a more-simple, preallocated-clone subVI test.  The time to allocate clones seems to grow non-linearly with the number of clones, so loading clone number 5001 takes a lot longer than clone 101.

I would be very interested to see your benchmark VIs -- I believe what you say, but there are several different reasons I can think of off the top of my head for this behavior, some of which could be worked around and some of which could not.

Attached is the simple, many-subVI test.  Basically just a bunch of VIs that statically load a lot of preallocated clones of a very simple subVI.  On my machine loading the initial 5000 subVIs takes 5 seconds.  40,000 takes 300 seconds, and loading an additional 5000 after the 40k takes another 88 seconds.  

-- James