DQMH Request Create Notifier and release notifier for every request, will it cause memory leak

[LV_COder]

For Request DQMH Obtain Notifier and Release Notifier for every request will it cause memory leak over a period of time. When Does LabVIEW deallocate memory? Does it deallocate memory immediately once we Release Notifier?

[joerg.hampel]

Hello LV_COder, thanks for bringing this up.

The short answer is "No, requesting a notifier reference and releasing it will not cause a memory leak over time. Memory will be returned when the reference gets released. This is why this design was chosen."

There is no long answer 🙂

Spoiler

Edit: Well, maybe a little elaboration is helpful. AFAIK, LabVIEW will usually not immediately free memory after a resource finishes, to avoid having to reallocate memory again for the same resource. Think about a Request VI: LV will allocate memory the first time the VI is run, and will keep the memory allocated. The next time you run the VI, the same chunk of memory can be reused. This is how it works, as far as I know, in layman's terms. Anybody, please feel free to correct me if I'm wrong.

[LV_COder]

Thanks, I have heavy reply payload, though using DVR, I have observed 2 times that memory is getting increased from 1gb to 3gb gradually, then suddenly from 3gb around it drop back to 1gb. Not Sure about this behavior. Code has been running for maybe 12 hours around, Any Suggestions 

[LV_COder]

It's something related to garbage collection? but still growing around 2Gb is huge.  

[Darren]

If your reply payload is a DVR, then the allocation to the actual data value shouldn't be affected by the use of the notifier. The data value may be gigabytes in size, but the DVR is only ever 32 bits. That's not going to cause an issue. I wonder if instead you should be investigating the data value itself, and places in your code where perhaps you are accessing that data and growing its size, making a copy, or something else.

Joerg is correct about allocation. Just because you call Release Notifier, Destroy Data Value Reference, Release Queue, Close Reference, Close File, etc. etc., doesn't mean LabVIEW immediately releases that memory. The LabVIEW Memory Manager decides on its own when it makes sense to deallocate because, again, as Joerg mentioned, things can be much more efficient when LabVIEW reuses memory that is already allocated. Sometimes people think they can call Request Deallocation to "force" LabVIEW to deallocate memory. But again, the LabVIEW Memory Manager is the ultimate decider... the function says 'Request' for a reason. 

[LV_COder]

Hi Darren, Thanks for the explanation, nowhere I am making copy or branching wire after reading from DVR.

Its repeatable now that memory is growing till 2Gb or 3Gb then dropping back to 1Gb. As it is getting back to 1Gb around always then definitely it's not memory leak, I think.   

Is it something with LabVIEW garbage collection or anything else?

[Darren]

LabVIEW doesn't have a garbage collector. It has a memory manager, as described in the link in my previous reply. The memory manager decides when to allocate and deallocate. There is something happening in your code causing the memory usage to grow, and then at some point when that memory is no longer needed, the memory manager is deciding to deallocate. There are profiling tools in LabVIEW that you could try (Profile Buffer Allocations is probably where I would start, it's in the Tools > Profile menu) if you are really interested in narrowing down where the large allocations are taking place.