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

[styrum]

Ok, OK, my bad, I left Debugging enabled. This is not a commercial app. This is is just some "food for thought", and something to play with, which you would otherwise not have the time to put together yourself. But now you can find some time (much less) to play with it. The goal was to get people to play with it, find flaws, "unfairness", etc. So I am glad that happened so quickly. Here is a version that has debugging disabled plus a "sequential" flavor of the whole thing.

Some disclaimers again:

1. Yes, I deliberately do not count the iterations completed by sender loops but not completed by the corresponding receivers by the time the senders are done, because I do want to count only fully completed "transactions" in evaluating "performance" .

2. No, I don't say that lossy and non-lossy methods are comparable "1 to 1" in general context. But for the declared purpose of this particular experiment, updating an indicator in a UI VI, where the user is interested only in the latest value ("tag"), it is fair to put them "together".

[styrum]

---

@Intaris wrote: But your calculation of "Iterations per ms" is wrong.  Instead of taking the last element of the protocol being tested, you need to take the number of times the consumer loop has iterated.

---

Another good catch! Thanks!

[altenbach]

Updating an indicator from a subVI is an UI issue and not time critical, so other things besides raw speed come in play (other measures of efficiency, threads, resource use, etc.). No indicator needs to be updated faster than the refresh rate of the monitor (or the speed of your retina!) so this is really quite an artificial test for pure benchmarking use, because hammering any indicator from anywhere is not such a great idea anyway. 😉 Not sure if there is any useful take-home message in all this. I haven't studied the (perceived) problem.

(I would also recommend to keep the discusssion on topic and leave the "air quotes" and nitpicking out of it. Thanks! You can ask the moderator to clean up your post if needed.)

[styrum]

---

@altenbach wrote:

Updating an indicator from a subVI is an UI issue and not time critical

---

True, but only in the sense that one shouldn't indeed try to update an indicator more often than is really needed (can be processed by a human). However it is not true in the sense that it doesn't matter how long each such operation takes, especially in the case of a "large" number of such indicators and, hence a well justified need for a (total) large number of operations. Moreover, "updating an indicator from a subVI" is only a "formal" purpose of the experiment, a means rather than a purpose even.

The "perceived" problem is IMHO an overuse of the event structure and its "user" events for the purposes that have nothing to do with interacting with a user. I mean making them the main method of asynchronous communication between different VIs running in parallel or just parallel loops within the same VI.

[Intaris]

None of these methods have to be tied into anything to do with UI (except the property node and my mentioned twelfth method).

If you find any of them lacking then just steer clear of them. There are frameworks out there which don't use them at all. You can program for years in LabVIEW and never have to use Method X. I, for example, have never used channels.

[Intaris]

If you go to the trouble of including lossless and lossy queues, you might want to think of doing the same for Events (not User Events). There you can also limit the size of the Event Queue.

[styrum]

Set Control By Index added. Wow, it is fast!

"Speed" calculation in the "sequential" version corrected to count the iterations of the receiver loops.

[styrum]

---

@Intaris wrote:

If you go to the trouble of including lossless and lossy queues, you might want to think of doing the same for Events (not User Events). There you can also limit the size of the Event Queue.

---

Can you elaborate? Which "Events"? Are you still talking about the Event Structure? Can we limit the length of its queue or generate a "lossy" user event which can force the structure to discard an earlier event not processed yet when the queue is full? I am on 2016 still. Is that possible in later LV versions?

[Intaris]

For static events (done as part of the event structure) there is an option on the UI for limiting the number of elements in that particular event queue. Set that to 1 and it is the event equivalent of a SEQ.

I'm on my phone. I cant really post an example. Here's a post at least dealing with the option. 

[styrum]

---

@Intaris wrote:

For static events (done as part of the event structure) there is an option on the UI for limiting the number of elements in that particular event queue. Set that to 1 and it is the event equivalent of a SEQ.

"Limit maximum number of instances of this event". Yes, I see. Too bad that is not available for "dynamic" events. But statically defined events which can be generated only by a user are not of interest here. It's the "user"/"dynamic" events I have a problem with being used where other methods would be much faster and produce less complicated code.