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

[styrum]

---

@crossrulz wrote:

---

---

Dynamic Dispatch is A LOT faster than converting a variant to data.  ....  As has been said, speed is not much of a concern in those situations; simplicity is more important.

---

Interesting how you are non-forgiving as far as performance is concerned in one place and forgiving in another. Do you realize that your argument can be used unchanged to defend the exactly opposite position (advocating using Vtd/StD instead of DD and queues instead of dynamic events)?

[cbutcher]

---

@styrum wrote:

---

@crossrulz wrote:

---

---

Dynamic Dispatch is A LOT faster than converting a variant to data.  ....  As has been said, speed is not much of a concern in those situations; simplicity is more important.

---

Interesting how you are non-forgiving as far as performance is concerned in one place and forgiving in another. Do you realize that your argument can be used unchanged to defend the exactly opposite position (advocating using Vtd/StD instead of DD and queues instead of dynamic events)?

---

Could you demonstrate that for me? I don't see it currently. 

Crossrulz started by confirming my expectation regarding VtD speed, then separately went on to highlight that in most cases where you'd use an Event Structure as part of a UI handling loop or similar, microseconds are less important than ease for the developer reading and writing.

You assert that this argument (please clarify exactly which argument you mean) can be equally applied in the reverse. I'm not certain what you mean by this. I'm concerned (especially given previous discussion regarding logical fallacies) that your quoting of his post misleads the reader by bringing together two mentions of speed from different contexts. The pronoun(s?) used in the second part of the quote don't reference the nouns in the first part, but that isn't obvious the way it is quoted.

[styrum]

Crossrulz (in the same comment!) touts speed of the resulting code over "the ease of developer reading and writing" in one place, when advocating use of DD vs VtD, but several lines lower says "simplicity is more important" (than speed) when he favors using dynamic events over queues.

So, a rather general dilemma arises: what should we choose,"the ease of developer reading and writing" or faster running resulting code in situations when one comes at a cost of the other? The vague universal answer ("it depends on application") won't do. Apparently, other factors should be considered, namely, by how much one option is faster/slower than the other and by how much one option is easier/harder to read/write. How do we then compare the total costs of both options, which would in turn break down into "short-term" and "long-term"?

By the way, you must have missed my comment where I show that "microseconds" difference in performance of queues vs dynamic events is actually a 4:1 ratio. And we are not talking about handling events generated by a human.

[styrum]

Oh and "Using dynamic events results in an easier to read/write code than when using queues" is ... questionable at the very least.

[styrum]

---

@crossrulz wrote:

---

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.

---

The worst thing you can do is to let the same event structure (and the loop around it) handle both user input (capturing buttons and mouse clicks) AND updating some indicators (or receiving messages from other VIs).  It is not "simpler", because you will have somehow to make sure you don't update those indicators (receive messages from other VIs) "too often" to cause problems with catching user input in a timely manner on the same FP.  And you will run into such a problem much easier than you may think. Whereas having a separate loop with the only things inside it being a Dequeue Element wired directly to the indicator that needs updating and using a Lossy Enqueue Element wherever you need to write to that indicator (via a single-element queue) solves the problem once and forever in all similar situations. And yes, you should have a separate queue (OK, at least a separate loop/event structure combo) to handle messages coming from other VIs, the frequency of which can become "too often" too very quickly.

[cbutcher]

---

@styrum wrote:

Crossrulz (in the same comment!) touts speed of the resulting code over "the ease of developer reading and writing" in one place, when advocating use of DD vs VtD, but several lines lower says "simplicity is more important" (than speed) when he favors using dynamic events over queues.

---

This is just not true. Crossrulz wrote that DD was faster than VtD, making no comment about ease of use and expressing no preference for one over the other in any situation. It's not unreasonable to read this paragraph as an endorsement of DD, but it's certainly not written there in that form.

In the second paragraph of Crossrulz's post, the topic is specifically (not a quote, paraphrasing) 'the loop which is handling GUI operations (user input, indicator updates from other VIs), typically using an Event Structure'. In that situation (and the comments are only specified in that situation) "speed is not much of a concern in those situations; simplicity is more important."

Here we see a claim that simplicity is more important than speed, when handling GUI operations. Nowhere in the post is there a claim of the opposite, merely that DD is faster than VtD, which may not even be relevant to your thread beyond your criticism (expressed as "well documented" without citation) of Actor Framework.

"We" may not be talking about handling events generated by a human from the point of view of this thread, taken as a whole, but specifically, Crossrulz was in that paragraph. The last few posts could be used as a great example of a 'strawman' argument.

---

@styrum wrote:

Oh and "Using dynamic events results in an easier to read/write code than when using queues" is ... questionable at the very least.

---

Personal incredulity is I think the label given to this one. I'd say it's fairly obvious. Which of us is right? Without some evidence, no way to know. We can each believe our own conclusions, or we could test, but I'm unsure what "proof" you'd accept here. Also, what's easier for me may not be easier for you, and so on.

---

@styrum wrote:

having a separate loop with the only things inside it being a Dequeue Element wired directly to the indicator that needs updating [details]... solves the problem once and forever in all similar situations

---

Why does your loop not throttle the UI handling Event Structure loop? I actually expect the answer here depends on the thread and execution priority settings, but I don't know that you can set those per loop, only per VI. Perhaps the compiler detects loops with event structures and automatically prioritizes those, but I'd have to see it to believe it.

Handling this is the UI loop adds complexity, but not so much.

This snippet demonstrates that when clicking Stop (the other Event case) when Flush is false, you have to wait a second or so if you run for a few seconds. Obviously the handling is slower than the event generation.

Setting Flush to true removes this delay. Clicking Stop allows the VI to stop "immediately". Obviously this is only from the point of view of me, clicking the button, and there is some time involved.

This VI took only a few minutes to write, the modification (adding flush) took maybe a minute, and I've never tried it before (I had to use the palettes! 😮 ). I don't think it can be considered a huge burden.

Edit: I added the VI, backsaved to 2015, for you to play with if you'd like (not sure how many people have already installed 2019).

[RavensFan]

I don't understand the point of this whole thread.

It started out as what seemed to be a very academic study of evaluating various methods of updating and indicator .  "Eleven ways ...."   "Relative Performances".

But it seems now to be a setup to just argue and justify the original poster's own personal belief system.  Even when Intaris suggests that benchmark methods can be highly flawed, and that the OP shouldn't take it as a personal attack against his methods,  the OP in the very next message acts like it was a personal attack.  Then goes on to rant about all the different types of valid and invalid arguments people make.  It sounded like those idiotic posts people make in Facebook political message threads where they want to sound smarter than they actually are.  You know, people who love to argue just for the sake of arguing.

It seems the whole point of this thread was to set up something just so the original poster can go attack some windmills.

[wiebe@CARYA]

---

@RavensFan wrote:

You know, people who love to argue just for the sake of arguing.

---

Engineers?

EDIT: forgot the , lets keep it light!

[crossrulz]

---

@styrum wrote:

---

@crossrulz wrote:

---

---

Dynamic Dispatch is A LOT faster than converting a variant to data.  ....  As has been said, speed is not much of a concern in those situations; simplicity is more important.

---

Interesting how you are non-forgiving as far as performance is concerned in one place and forgiving in another. Do you realize that your argument can be used unchanged to defend the exactly opposite position (advocating using Vtd/StD instead of DD and queues instead of dynamic events)?

---

The two paragraphs are from completely different thoughts.  The first was just answering a general question on performance.  Just fact, no opinion on the results or what it means.  The second paragraph is purely my opinion on why I prefer using User Events.  An even with some high rate messages (events) coming through, I have yet to have my GUI suffer due to User Events.  When I do, I will then consider a more complicated architecture.  But until then, simplicity.

[styrum]

Wow! All the way down to accusations of arguing for the sake of arguing and personal incredulity. Even the word "idiotic" showed up. Where is a Block button here?

Lets keep it light indeed and maybe wrap up already.

"Take home" for me:

The event structure's queue is SEVERAL TIMES (hundreds of percent) slower than a regular queue. It is confirmed by the "06..." benchmark code mentioned above and "crappy benchmark" neither of which is mine. So, there is no flaw in my benchmark code, at least as far as that particular result is concerned.

The features of the events queue flushing function (ability to selectively flush only certain types of events and/or only from certain objects) are unmatched by the features of the corresponding flush function for regular queues, which indeed allows to utilize the same event structure for both processing user input and updating indicators even when indicator update events come "too fast". Flushing won't help, though, when you can't afford discarding a message you handle with the same event structure which comes, say, from another "actor" VI, and those messages come too often to not interfere with capturing user input by that event structure just because they both go into the same (several times slower than a regular) queue.

An "easier" setup of 1 to N communications is another factor in favor of using dynamic events and the events structure instead of regular queues for messaging architectures.

DD vs VtD and/or S("flattened string") to Data from the "Simplicity vs Speed" prospective is indeed a separate topic and maybe an object for another benchmark, just to see how much faster/slower is one over the others.

How much one particular way of coding something is "simpler" than another is indeed subjective. Moreover, "easy to write" code is not necessarily easy to read and it is much more important for it to be easy to read than easy to write.

To ignore all of the above or take into account is up to whoever considers corresponding alternatives in his unique set of circumstances.

Peace.