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

[Intaris]

There is a function to flush the event queue for user events. I've never done it but I think it can create similar functionality.

[styrum]

Yes, I know. I even considered an additional option: to flush the event structure queue and the non-lossy regular queue after each read or not. It won't help the event structure win though. You can easily add those flushes to both and see for yourself.

[mcduff]

---

@styrum wrote:

---

I have the impression that you don't like User Events. May I suggest you look at the following, if you haven't already,

EDIT: Link Below no longer works

https://libraries.io/github/JackDunaway/LabVIEW-User-Events-Tips-Tricks-and-Sundry

There is an excellent benchmark there comparing queues to User Events.

Spoiler

There is not a big difference.

Anyway, even if you don't like the benchmark, maybe you will change you mind about User Events.

mcduff

EDIT: Try this link

https://github.com/donyaco/LabVIEW-User-Events-Tips-Tricks-and-Sundry

[BertMcMahan]

Another thing to consider about User Events... I haven't heard this from "official" sources, but if I were a betting man I'd put my money on them being user *defined* events, not user *generated* events.

The "user" here is the programmer, not the end user of the program. They're not supposed to simulate things being done by a user- though they CAN do that- they're just defined by the programmer, not by NI, hence it's a *user* event.

[styrum]

---

@mcduff wrote:

---

I have the impression that you don't like User Events. May I suggest you look at the following, if you haven't already,

EDIT: Link Below no longer works

https://libraries.io/github/JackDunaway/LabVIEW-User-Events-Tips-Tricks-and-Sundry

There is an excellent benchmark there comparing queues to User Events.

Spoiler

There is not a big difference.

05 - Demonstration - High Throughput Transport Mechanism.vi from that set says:

What I can see from my experiment is that they are MUCH worse. Will be glad to see a proof to the contrary. As far as I can see, your code doesn't do a direct test bed comparison like mine does. 

[altenbach]

---

@Intaris wrote:

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

---

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

Updating an indicator is a pure UI function. Maybe this thread is about something else. Who'd know? 😄

[mcduff]

I get this from the benchmark.

Also look at 06 - Benchmark - Event vs Queue Speed. The difference in speed is in the microseconds. (In the same project)

What I can see from my experiment is that they are MUCH worse. Will be glad to see a proof to the contrary. As far as I can see, your code doesn't do a direct test bed comparison like mine does.

My gut feeling is your benchmark/experiment is flawed. Altenbach, who has replied in this post, wrote/gave an excellent white paper/talk about benchmarking and all that needs to be done to ensure the results are correct. From what I gather from altenbach's white paper is it is quite difficult to design a good benchmark. The project that I linked to is from a LabVIEW architect/champion; my gut just happens to trust his benchmark a lot more than yours. No offense.

mcduff

[styrum]

Your "gut feeling" is not a valid argument. Neither is Appeal to Authority (argumentum ad verecundiam) in a correct discussion. Please find a flaw in my setup or do not make such claims.

[Gregory]

---

@styrum wrote:

---

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.

---

The choice to use dynamic events does not come down to whether or not the user is interacting with an event structure or not, it just depends what kind of messaging architecture you need. Queues are great for 1:1 messaging (1 sender, 1 receiver), and could be used for N:1 messaging. However, for 1:N messaging, events become a simpler and more scalable solution. As Jack Dunaway's presentation shows, queues are usually a tad faster, though it depends on the data size and number of packets, and the choice rarely comes down to which one is faster.

[styrum]

What really matters is not the absolute difference in times per "message" (sending plus processing), but the relative one. If some action  takes "a few microseconds" more than some other action, then the duration of either action also matters in deciding whether it is a significant difference or not. It is one thing when one action takes 1000 microseconds and the other takes 995. And it is a a completely different situation when one action takes 6 microseconds vs. 1 for the other. In both cases the absolute difference is the same, 5 microseconds. Would you (dare to) call it "insignificant" in the second case? And here we are apparently dealing with the second case: