Persistent Data Value Reference (DVR)

[EthanStern]

I have long defended NI's decision to bind the lifespan of DVRs to their creator VI but, with the addition of malleability (totally awesome) and the fix in LV 2020 that allows "New Data Value Reference" to be called directly in an inlined VI (thanks, AQ), the ephemeral auto-cleanup behavior of DVRs is now a big blocker to a reference-based strictly-typed API.

I want to open a strictly-typed and malleable reference and keep that reference open until I choose to close it, regardless of whether the opener leaves memory. Without malleability, I could delegate the DVR creation to another thread/VI and get the persistent reference back by callback but I can't have the home-baked persistence and the malleabilty.

 

Please add a persistence/auto-cleanup flag to New Data Value Reference so I that reference can persist if I want it to. (I need both the persistence and the malleability to write some really cool code.)

Here's an old request for this feature that was declined, but things have changed a lot since then: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Persistent-DVR-s/idc-p/2856348#M27799 

[drjdpowell]

FYI: my notes on avoiding copying with large by-val objects:   

https://forums.ni.com/t5/JDP-Science-Tools/Notes-on-Memory-optimization/m-p/4412690

It is a lot of work, and using DVRs is much simple, but it is possible.

[wiebe@CARYA]

>It is a lot of work, and using DVRs is much simple, but it is possible.

But at least some of those tips still apply when you use a DVR.

For instance "prevent copies of an added array element by adding an empty element first then swapping in" would still be needed to avoid copies with a DVR solution, both for an array of DVRs and a DVR of an array of objects.

A DVR has never made anything simpler for me. Debugging DVR code is so much harder, I always end up spending a lot of time refactoring them out. I obviously don't put them in in the first place unless it's a very, very last resort, but I do inherit code.