DQMH overhead

[1984]

Hi,

I'm wondering if there is an already worked out number for DQMH overhead compared to inline VI calls. According to my experiment the overhead of a Request and Wait for Reply type call is about 20-25us.

The method I used: simply compared to call an empty VI inline for 1M times and compared it to calling an empty DQMH event also for 1M time. Standard inline call took about 200ms, DQMH took abou 19000ms. 19.000/1M =~ 20us

Could somebody confirm this, or send me more accurate numbers?

thx!

[joerg.hampel]

Can you give more context for your benchmark?

I'm honestly wondering why to compare those two use cases: If you can get away with a simple inlined VI, why would you instead go with a DQMH request? And if you have the need for using a DQMH module (for whatever reason), does it really matter how long an inlined VI would take? 

Also, calling an empty inlined VI should be a non-op...

[1984]

I'm experimenting with DQMH. I have a set of functions developed which could be a good candidate for moving to a dqmh module, but first I'd like to understand how much overhead DQMH creates. Could be that the logic is not that reasonable behind this.

Pretty much any design pattern can be substituted with something else. I mean I could code the CML example a very different way. From this aspect my feeling is that going with a certain design pattern is a matter of choice. If you stick with your choice your code will look more uniform, but that comes at a price that certain things could have been done in an easier way. Not sure if my reasoning makes sense, but I hope so.

But anyways... if we are talking about use cases, I'm definitely wondering about the articulated use cases of the DQMH pattern? What is your typical project in terms of the proportion of the DQMH modules vs non DQMH stuff? What are the main decision making factors when you decide if a certain part of the code should be done in DQMH?

Let me know your thoughts.

[joerg.hampel]

---

@1984 wrote:

Let me know your thoughts.

---

I'm not the best person to ask for advice here. I'm known to be heavily biased - our Dokuwiki even has a page dedicated to HSE's advantages using DQMH!

You can see what a typical project of ours looks like here: https://dokuwiki.hampel-soft.com/code/dqmh/hse-application-template. This is our template for Windows-based applications, and most design decisions and reuse libraries also apply to our Real-Time applications. It's open source and free, so take a look and see for yourself.

As for our decision tree: It's quite simple. Everything has to be a DQMH module, unless there is good reason for not making it a module. An example would be an abstraction layer, where we want to use OOP to override behaviour through inheritance (either wrapping a DQMH module inside a class or putting the class on the shift register inside the module). Also, I can't remember ever thinking "if only I had not made this a module", whereas there have been a few occasions where I thought "heck, why haven't I created a module in the first place!". 

Our (HSE's) whole "why" is working with teams, helping teams improve, reducing headache and trouble for and within teams. Uniformity, cohesion, modularity, a defined architecture and style make collaboration on code within and across teams easier - hence our strategy.

[Olivier-JOURDAN]

Basically the same as @joerg.hampel 

Almost everything is a DQMH module in my applications.

I can only see exceptions for the VI that launches my apps and for some "simple" dialog boxes.

Execution times issues I had since I'm using DQMH weren't related to the framework.

If I have part of my code with a critical timing requirement, it's totally possible to write it without DQMH.

The advantages given by creating a DQMH module are almost always more important than the possible drawbacks.

From my own experience, the feeling that "certain things could have been done in an easier way." comes more with how comfortable you are with the tech used or with more straightforward use cases in mind that will not cover all the possible framework usage.

If you are evaluating frameworks before choosing one, I would recommend answering the following questions:

- Do I agree with the framework philosophies (for the DQMH: testability, ease of use…) 

- Does the framework can be used by all of my team?

- Does the framework is continuously improved and maintain

- Can I find support

- …

Replies to these questions may lead you to a different framework…  

[Taggart]

---

@joerg.hampel wrote:

---

@1984 wrote:

Let me know your thoughts.

---

I'm not the best person to ask for advice here. I'm known to be heavily biased - our Dokuwiki even has a page dedicated to HSE's advantages using DQMH!

You can see what a typical project of ours looks like here: https://dokuwiki.hampel-soft.com/code/dqmh/hse-application-template. This is our template for Windows-based applications, and most design decisions and reuse libraries also apply to our Real-Time applications. It's open source and free, so take a look and see for yourself.

As for our decision tree: It's quite simple. Everything has to be a DQMH module, unless there is good reason for not making it a module. An example would be an abstraction layer, where we want to use OOP to override behaviour through inheritance (either wrapping a DQMH module inside a class or putting the class on the shift register inside the module). Also, I can't remember ever thinking "if only I had not made this a module", whereas there have been a few occasions where I thought "heck, why haven't I created a module in the first place!". 

Our (HSE's) whole "why" is working with teams, helping teams improve, reducing headache and trouble for and within teams. Uniformity, cohesion, modularity, a defined architecture and style make collaboration on code within and across teams easier - hence our strategy.

---

My decision-making is slightly different from Joerg's.

It's a simple question - does this thing need to be asynchronous? If the answer is no, there is no reason to use DQMH. Make it a class or library.

I have seen DQMH modules where every single message is a request and wait for reply and I wonder why bother adding the complexity of DQMH? (there is one use case involving TestStand that makes sense, but other than that it just seems like added complexity for no benefit.)

If the answer is yes it needs to be asynchronous, then you have to decide which asynchronous messaging framework to use. My default for that at the moment is DQMH. To Joerg's point, there is something about consistency. As a consultant, I work with a variety of clients. Sometimes they use AF or other things, if so, then I use whatever framework they use to be consistent.

[Taggart]

---

@Olivier-JOURDAN wrote:

If you are evaluating frameworks before choosing one, I would recommend answering the following questions:

- Do I agree with the framework philosophies (for the DQMH: testability, ease of use…) 

- Does the framework can be used by all of my team?

- Does the framework is continuously improved and maintain

- Can I find support

- …

Replies to these questions may lead you to a different framework…  

---

If only someone made a presentation about that.

https://youtu.be/8cEBXNpXFkI

[Ozfarmboy]

---

It's a simple question - does this thing need to be asynchronous? If the answer is no, there is no reason to use DQMH. Make it a class or library.

I have seen DQMH modules where every single message is a request and wait for reply and I wonder why bother adding the complexity of DQMH? (there is one use case involving TestStand that makes sense, but other than that it just seems like added complexity for no benefit.)

My decision is a slight tweak:  Does this thing need a user interface?  If yes, then a class or library is not sufficient.  But that still aligns with your comment Sam, in that adding the UI makes it asynchronous in most cases.

Also, I wrote a detailed description of when we choose to create a module or not here:

Solved: Re: DQMH Register for Events height for large "ish" applications - Page 2 - NI Community

[Olivier-JOURDAN]

---

@Taggart  a écrit : If only someone made a presentation about that.

https://youtu.be/8cEBXNpXFkI

---

😅

[1984]

Thanks everyone for sharing your thoughts.