Eleven Ways to Update an Indicator from within a subVI. Their Relative Performances and Quite Far Reaching Consequences...

[styrum]

Yes, setting 1 to N communication ("broadcasting", "publishing") can be the only advantage of dynamic events over queues. But considering the difference in performance it may still be better(faster) to send the same message to a number of subscribers' queues than use the dynamic events for that purpose. And it it will definitely not make the code more convoluted.

[styrum]

---

@altenbach wrote:

---

---

... and the title of this thread: "Eleven Ways to Update an Indicator from within a subVI" 😄

---

But it's not the entire title, is it?

[styrum]

Hey, look! My experiment result actually agrees with the average result from the "06 - Benchmark - Event vs Queue Speed.vi"! It is about 4:1 too! So, a regular queue is indeed (on average) FOUR TIMES faster than an event structure with a user event set up to process the same data.

[mcduff]

---

@styrum wrote:

. Please find a flaw in my setup or do not make such claims.

---

Without much effort I can increase the User Event Case in your setup by deleting both the timeout and stop user event. (I used a comparison to stop the loop.) Just saying.

[styrum]

---

@mcduff wrote:

---

Without much effort I can increase the User Event Case in your setup by deleting both the timeout and stop user event. (I used a comparison to stop the loop.) Just saying

---

I just removed the Timeout case. 865 vs 182. OK, removing the Stop case really helped, 824 and 377. So, still 2:1.  What numbers did you get?

Note that, event structures are not used with a single case in the architectures I mentioned. They are set quite on the opposite set to handle too many dynamic events.

[mcduff]

Attached is a crappy benchmark; I'm tired of this game.

Queues are faster than User Events, in my crappy benchmark 3 us to 1 us. For a Windows OS that difference typically gets lost in the noise. As said before there are other advantages of User Events as you showed in your first benchmark; you are subscribing to two different messages a stop and number, show me a queue that can receive two different data types from the same wire.

mcduff

PS You forgot to test Occurrences; fastest way to trigger anything in LabVIEW. They don't even need a datatype.

[styrum]

---

@mcduff wrote:

Attached is a crappy benchmark; I'm tired of this game.

Queues are faster than User Events, in my crappy benchmark 3 us to 1 us. For a Windows OS that difference typically gets lost in the noise. As said before there are other advantages of User Events as you showed in your first benchmark; you are subscribing to two different messages a stop and number, show me a queue that can receive two different data types from the same wire.

mcduff

PS You forgot to test Occurrences; fastest way to trigger anything in LabVIEW. They don't even need a datatype.

---

I am glad you finally agree with me. Dynamic events lose badly to queues. 3:1 or 4:1 is not a fundamental disagreement.

No, I didn't forget about occurrences. I actually wanted to use them in the "paprallel" version of my code instead of the Boolean "watchdog" queue. That may still be a good idea because I suspect that Preview Queue Element takes too big a fraction of the entire sender loop iteration time. Occurence is fast to trigger but it can't carry data so how could I use as a "method" in this experiment, in a pair with a global variable?

Oh, so you worry about "type safety" too? You can pass any data type in a variant or flattened string using a queue. Yes, your receiver better know how to interpret the message data depending on the message name. I find that whole argument that lead to making a separate class (including a method to process the message, a heresy from the decoupling principle point of view!) for every message in AF very... weak.

3-4 to 1 difference is "lost in the noise"?! Well, it really depends on how many such messages get sent per unit of time. Again, I was not talking about using "events" generated by a human (which the Event Structure is indeed very good at and apparently was designed for).

[cbutcher]

I think it's just type safety, not "type safety". And sure, why not? Strict typing is great.

Actor Framework specifically chooses to inflate the number of necessary VIs and Classes in order to provide this strict type checking, along with trading Variant to Data for Dynamic Dispatch. I haven't tested (and as we've seen in this and many other threads, accurately benchmarking is hard work, so I won't test either until I actually need to for something) but I'd guess based on reading around the forums and knowledgebase and so on that probably DD is faster than VtD. If anyone knows differently, I'm happy to be educated.

As to coupling, in AF you're coupling via the message class with the simplest method. More advanced messaging methods are possible, for example, the so-called "zero-coupling" messaging, which makes the coupling only one-way (caller knows callee, callee doesn't know caller, allows making reusable callee modules). Casey Lamers gave a presentation at NI Week 2018 that showed even more decoupled code.

In the (Enum + Variant) message case, you have some coupling from the enum, potentially. Of course, you can remove that by using a String, but you still need the datatypes for VtD. If these are non-trivial, you're coupling to a typedef or duplicating code (and potentially coercing if using shared VIs with different typedefs). Is this tradeoff worth potential typos? Of course, it depends on your application...

[styrum]

The ... deficiencies of Actor Framework (its particular NI's implementation) have been well documented long time ago. Lets not discuss them here.

[crossrulz]

---

@cbutcher wrote:

but I'd guess based on reading around the forums and knowledgebase and so on that probably DD is faster than VtD. If anyone knows differently, I'm happy to be educated.

---

Dynamic Dispatch is A LOT faster than converting a variant to data.  A DD almost compiles down to just a case structure.  But VtD is SLOW, most likely eliminating any benefit of data transport speed we have been discussing here.  Need to find time to create a benchmark (still stuck in a dark tunnel, but I see a light coming).

My general thoughts on User Events: All GUI operations (user input, indicator updates coming from other VIs) should be done in a single loop.  That loop almost always uses an Event Structure.  So User Events fits in perfectly as you can just add to the Event Structure to handle the message instead of a completely other loop to manage a queue, notifier, etc.  As has been said, speed is not much of a concern in those situations; simplicity is more important.