Actor Overload!

[AristosQueue (NI)]

Ah. I thought you were asking about the runtime behavior... didn't realize you were talking about the edit time behavior.

Yes, there's pain at some point there. You don't see it at projects on the scale of 35 classes used for the evaporative cooler example. You do see it if you start heading up toward 100 classes. While I would love to see that pain fixed, the time delays in the editor as I work on projects of that scale are miniscule compared to the real loss of time to bugs I cannot track in larger programs without the good architectures.

[KuGr]

Fabric,

Regarding update time for class properties, private data, etc, I was just wondering how many classes are in lvlibs and how intertwined the lvlib dependencies are?

In short, I have abandoned lvlibs.   I am not advocating this, it is simply my solution to handling a developing framework that happens to be based on AF.  I have left AF in its original lvlib, by the way.  There have been a number of threads on base class changes causing LV to become very busy.  For example, search on the lava site for "dirty little secret" and on the top result is a thread started by mje.

LVB: sorry for hijacking the thread.  This is not AF related, but Fabric struck a nerve.

Kurt

[David_Staab]

(reply to entire subthread)

fabric, you hit my #1 complaint on the head. The editor is grinding to a halt under my project that only contains ~50 classes so far. I need to bring it up to 100-150, and I'm seriously concerned about the decreasing value of my time as a contractor when I have to wait 5-10+ sec to perform trivial actions in the editor. I'm cranking out code faster every day, yet my progress toward product deliverables is slowing as the software project grows. I did NOT have this issue developing the RT and FPGA pieces of the project, which were implemented using AMC in RT and without classes in FPGA.

Kurt Grice unwrapped one layer of the problem's cause, and that's the advice that AF actors be wrapped into a library with their associated messages. Libraries have terrible performance costs, both in edit-time speed and run-time memory bloat, and after trying to follow AF canon for the first half of my this project, I agree that they should generally be avoided altogether. If two messages intended for different recipients share the same name, prefix them.

Libraries only amplify the real core cause of the problem, though, which is that under AF all your classes are linked to each other. LV's in-time compiler chokes every time you change anything in the hierarchy. Right now, I can add a data member to a large class for a custom waveform integrator and watch LV crunch on the change for over 1 min, then ask me to save 96 files. The class only contains ~30. Don't get me started on the effect AF is having on my source control repository.

AQ's response is frankly unsatisfactory to these complaints. Most LV developers aren't working on large projects, we're working on mid-size and small projects. AF's benefits are quickly wilting in the searing heat of LVOOP's drawbacks. I want to use actor-oriented designs to minimize project risk for my clients, but I can't make AF the tool for doing so if it pours molasses into the swimming pool. (Is that a real metaphor? I think I just made that up...)

(I still haven't had the time to post about the punishment you receive when you decide to change the interface to a class method. Scripting new code is easy with the Message Maker, but if the developer changes his mind or makes a mistake, he suffers the need to edit 3x as much code to rectify it. And again, that causes a bigger hit on his SCC repo changelist.)

[David_Staab]

niACS wrote:

See, I tend to think AF is quite appropriate in applications with lots of UIs.  The launch and stop mechanisms are already written, communication between the UIs and the rest of the application is already worked out, and the UIs are easy to write.  Because of this, the framework greatly simplifies model-view-controller designs.  Why would I not use AF in that case?

MVC isn't appropriate for apps that lack certain requirements. But as I said in my post, I'll elaborate when I have the time for a full dialogue.

niACS wrote:

Also, point of order, the out-of-the-box bugs are with LabVIEW RT, not with AF.  The issue is with community scoping on VxWorks; any application that uses community scoping is problematic.

It's all LV to your end user. The Actor Framework is broken on Real-Time targets that are meant to be programmed using LabVIEW because it employs a buggy feature. You can point fingers within your organization all day deciding who gets hanged for it, but it won't change the fact that I'm left with an NI tool that doesn't work when I need it.

AristosQueue wrote:

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

Again, you're missing the mark. (This kind of response belies that "R&D" mentality I hated when I worked there: "Not my feature, not my problem!") The entire point of LVRT is to obscure the fact that you're working on VXWorks, or PharLap, or whatever OS. It's an abstraction from the grim realities of deploying code to a real-time target. If your customers have bought into the platform message, they trust you to keep that abstraction whole so they can choose any new RT target and know their code works the same as it did on a different one. You can't start creating leaks in the abstraction without diminishing its effectiveness. Who is going to write portable LVRT code in AF if they know it might not work on the next target their client/customer chooses for deployment?

[justACS]

niACS wrote:

Also, point of order, the out-of-the-box bugs are with LabVIEW RT, not with AF.  The issue is with community scoping on VxWorks; any application that uses community scoping is problematic.

It's all LV to your end user. The Actor Framework is broken on Real-Time targets that are meant to be programmed using LabVIEW because it employs a buggy feature. You can point fingers within your organization all day deciding who gets hanged for it, but it won't change the fact that I'm left with an NI tool that doesn't work when I need it.

Words and names matter; they create lasting impressions.  The patch to the issue in question is coming, but it will be listed as a LVRT patch, not a fix to Actor Framework.  If we refer to this issue as a problem with Actor Framework, then we may find ourselves fighting the misconception that AF doesn't work on RT long past the time when the underlying LVRT issues have been resolved.  We're fighting that fight now with dynamic dispatch on RT (which has been fine since 2009), and I don't want to have the same kinds of arguments over AF in 2015.

[AristosQueue (NI)]

This will be my final reply on this thread.

LabVIEW classes are successfully used by thousands of people globally. There is a threshold of scale within the editor where slowdowns become noticable. That threshold is quite high. At "small" and "mid," you're not in the molasses. They crop up at "large." I work with one hierarchy of 1500+ VIs and ~200 classes. The slowdowns there are noticeable (10+ seconds) and annoying, but not enough to showstop my development. If you are really working at that scale, I appologize for the inconvenience. If you are below that scale, your wait will be less (and since the curve is non-linear, probably substantially less).

LabVIEW R&D, and, indeed, all of NI, delivers the best product we can. We try very hard not to cut corners in our hardware or our software.  As with any software product, there are sometimes bugs at the time that we release a product, some known, some unknown. We manage our bug lists to the best of our ability. Our customers, luckily, are also software engineers, and we expect a certain amount of understanding for the realities of software business needs. We make choices about what to fix and what to let slide every day. In general, we have a good reputation for communicating our screw ups to our customers and for promptly fixing the most egregious issues. But there will be issues that are particularly problematic for some customers that we do not address. That is also a fact of the software industry. If you are willing to work with us as we try to correct the issues, we can help you be productive more often than not, and any time we cannot help will be amortized over time. If, on the other hand, you expect us to achieve perfection and/or to prioritize your bugs above other bugs affecting other customers, the conversation breaks down. If over time you feel that we are completely ignoring you as a customer, you should find a new vendor to work with. You will be happier than trying to fight with us over every issue. If enough customers do this, we will definitely change how we handle these issues, but at this time, we feel we have a good balance between the desire to ship a quality product and a desire to make a profit. I do not like to encourage people to walk away from LabVIEW, but I think of Santa in Miracle on 34th St. encouraging shoppers to go to a different store -- sometimes that's what it takes to make your customers actually happy. And perhaps you'll come back someday and be pleasantly surprised that we have what you're looking for.

[LVB]

It seems this thread just veered off a steep cliff!  First of all, thanks for your discussion on the original topic of this thread (design patterns and when to use the AF).

Daklu wrote:

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

...

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.    )

...

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.)

I think you just summarized why people use a QMH/JKI State Machine: the ability to write (non-reusable) code quickly.

I did attend Norm's presentation, and would like to review his slides and code when they become available.  What "state machine" would you suggest if not using the AF?  I am really interested in placing an easy to understand "state machine" inside the Actor Core as a building block towards actor oriented design.

[LVB]

AristosQueue wrote:

Ah. I thought you were asking about the runtime behavior... didn't realize you were talking about the edit time behavior.

Yes, there's pain at some point there. You don't see it at projects on the scale of 35 classes used for the evaporative cooler example. You do see it if you start heading up toward 100 classes. While I would love to see that pain fixed, the time delays in the editor as I work on projects of that scale are miniscule compared to the real loss of time to bugs I cannot track in larger programs without the good architectures.

Thanks for the advice.  I think this thread confirmed my understanding of when to use an actor.  Also, a lot of good information on the performance of the application and LabVIEW IDE when scaling to large applictions.

[fabric]

Kurt Grice wrote:

Fabric,

Regarding update time for class properties, private data, etc, I was just wondering how many classes are in lvlibs and how intertwined the lvlib dependencies are?

These days, most of my classes live in lvlib libraries. The dependencies are often other small "helper" libraries which I try to keep relatively self-contained (e.g. a "string" library or a "2D SGL array" library), but in practive the helper libraries often need to depend on a few other small helper libraries. Often my classes depend on other small data classes (composition/aggregation), but I generally try to keep those classes as self-contained as possible too. Seems normal enough...

The lvlib approach keeps things nicely organised and nicely name-spaced, but I have noticed a serious performance hit when compared with a using a bunch of standalone VIs/ctls on disk. Unfortunately I really enjoy the benefits of good project organisation, so the prospect of discarding all those libraries is pretty unappealing. That said, IDE performance is sometimes SO bad that I'm tempted to try anything... (even giving up lvlibs!)

Bringing this back on topic, I think AF is well suited to:

• Most small projects - however the benefits of a highly robust underlying architecture are often not felt on small projects;
• Most mid-sized projects - however not unless you are willing to put up with considerable edit-time pain. I'd also add that a decent pencil/paper design is pretty critical before you start coding or that edit-time pain is amplified considerably. As DavidStaab mentions, reworking/tweaking an existing AF design generally involves *much* more overhead than reworking a simple state machine;
• Very few large projects. I say this not beacuse AF is "not capable" of supporting a large project, but purely because it becomes much harder to "avoid pain" with a large project. Yes, good architecture becomes even more important as your project scales up, but framework overhead becomes increasingly significant as your project scales up too. In my experience to date, AF is much too heavyweight to be efficiently used on a large project...

[onnodb]

Sorry to see that this thread is causing discomfort!

I'd like to stress that, for me and probably many others, the AF feels like a huge improvement. I've been greatly enjoying the way it's helped me to improve my application's architecture.

I also agree with the people here that, as the project I'm working on is growing larger, I'm running into difficulties with molasses and swimming pools, as far as the IDE is concerned. (And few things irk the programmer's mind as much as perceived sluggishness). My guess is that this is just part of the evolution of LabVIEW, and expected as more and more people are pushing the IDE's boundaries in the LVOOP area. The AF is great framework, but maybe it stresses some areas in LabVIEW that might not be fully optimized yet?

Hopefully, this thread can serve as a signal that there's room for improvement in this area. Should this get priority from R&D? I'm sure you guys have plenty of juggling balls to keep in the air. In the meantime, *I* am definitely going to stick with the the AF