Efficient way to use DVR in DQMH modules

[AdarshaPakala]

Ozfarmboy:

Is the constant allocation/deallocation of memory occurring because DVRs are being constantly created/destroyed going to create a determinism issue?  I am think especially for RT here

I had the similar question, What is the memory allocation/deallocation overheads in very frequent DVR create and destroy option(lets say every 50mS) for 24x7 running application?

Thank you

[TiTou]

One additional suggestion for you, in case the data type you stream changes over time, you can typecast the DVR ref into a U32 to make it "embedded-data-type agnostic".

If you do that, when you typecast back from U32 to DVR ref, place the "create DVR" primitive in a disable struct and the data type out of the disable struct 😉

[drjdpowell]

---

@TiTou wrote:

One additional suggestion for you, in case the data type you stream changes over time, you can typecast the DVR ref into a U32 to make it "embedded-data-type agnostic".

---

Putting the DVR in a Variant is a safer way to do this, in that you wont crash the program if you cast to the wrong datatype (you'll get an error instead).

[TiTou]

...and I was wrong to think that the to-variant + variant-to-data would take longer to execute, it's the same!

I hope LabVIEW will find other ways to crash 😮

[AdarshaPakala]

What is the memory allocation/deallocation overheads in very frequent DVR create and destroy option(lets say every 50mS) for 24x7 running application?

Any thoughts on this?

Between, Thank you for all your replies, its all great information.

Thank you

[drjdpowell]

---

@AdarshaPakala wrote:

What is the memory allocation/deallocation overheads in very frequent DVR create and destroy option(lets say every 50mS) for 24x7 running application?

Any thoughts on this?

---

My thought is to wonder why you haven't just measured DVR overhead with a simple test VI.  Make and destroy 10,000 DVRs per second and run that overnight.

[AdarshaPakala]

I already did that. I was wondering, I would get more information, if some one already had experienced with bigger application in this scenarios. The behaviour could be different in bigger applications when there is a lot of thread switching, thermal managing/throttling,  large memory management and etc are happening.

[drjdpowell]

So you are asking if anyone with experience using DVRs in this way has had any problems.  That is a better question.

[UliB]

---

@Olivier-JOURDAN wrote:

---

@joerg.hampel  a écrit :

I guess that it's alright to send the DVRs via plain old broadcasts, right? Seeing as it's only the reference we're sending, we don't need to be concerned about the data copies which the event system creates ?

---

If creating a broadcast with an array in the first module and registering the second module to listen to the broadcast is not performant enough, it's fine to replace the array with the DVR ref. I'm not aware of any data copy doing that.

The trick of option #1 is to set the value when you create the DVR and retrieve it. When you destroy the DVR, you never have to read or write the value.

---

I too have been thinking about sending a DVR with a broadcast event. My question is: Where should I destroy the DVR?

In DQMH there is a unknown number of listeners to the broadcast. At a minimum there is one parent module and there is one tester and both can run without the other or at the same time. 

Is it a must to only listen in the parent to this broadcast and to destroy the DVR in the parent?

What happens to the DVR in case you run the module from the tester? Does the module has to know that it is run from the tester and in this case doesn't create the DVR at all?

[Olivier-JOURDAN]

@UliB, IMO, using DVR to share data between modules, should only be used when the classic method can't reach the expected performance.

Without knowing your context, I'd first try to have only one target for my data. The sender module creates the DVR and the Receiver destroys the DVR. You can send the DVR with a broadcast or a request. This choice won't be directly related to the use of a DVR.

If you really need to share data with multiple modules, I would only share the DVR ref once with the target modules, and give the responsibility of destroying the DVR to the module that generates the data.

Of course, ensuring that all modules receive and process all the data will require some handshaking at some point.

As I said at the beginning of my message, if you need to use DVR, you may have constraints I'm not aware of, so take my message as it is, just some basic thoughts on hox to proceed and first make sure you really need a DVR 😉