Releasing memory to the OS

[tarheels100]

TL;DR: What is LabVIEW's procedure/time-frame for releasing memory back to the OS?  Is there any way to ensure that LabVIEW gives up unused memory resources (i.e., to the OS) from queues, variant attributes, DVRs, etc. after they are destroyed/deleted/empty?  If not, is there at least some way to have the memory released once the VI is finished running (idle)?

<rant and background information>

When it comes to memory management in LabVIEW, there seems to be two main aspects:

1. deallocating memory but retaining it for later use by LabVIEW, and
2. releasing unused memory to the OS. 

It can be hard to determine when and how these two processes take place.  While neither is well documented or frequently discussed online, releasing memory to the OS is particularly enigmatic.  While automatic memory management and garbage collection is a wonderful thing (and I'm glad LabVIEW has it), it can be a hindrance in certain situations, especially when its behavior is not predictable and clear to the user. 

LabVIEW is relatively liberal with its retaining of memory, which is often cited as a speed benefit since it can prevent repeated deallocation and reallocation of memory resources.  However, in cases where a queue or other data structure must temporarily grow to a significant fraction of the system memory, it is important that at least some of the memory be returned to the OS after the operations is complete or else the entire system can come to a grinding halt.  In many cases, LabVIEW will hold on to this huge chunk of unused memory even when the system memory is completely full and will not release the memory after the program is finished running.

</rant>

[Yamaeda]

From Request Deallocation help

"When a top-level VI calls a subVI, LabVIEW allocates a data space of memory in which that subVI runs. When the subVI finishes running, LabVIEW usually does not deallocate the data space until the top-level VI finishes running or until the entire application stops, which can result in out-of-memory conditions and degradation of performance. Use this function to deallocate the data space immediately after the VI completes execution."

So in your scenario i'd put a Request Deallocation in the Empty queue function.

/Y

[tarheels100]

Yamaeda:

Thanks for the suggestion.  I've experimented fairly extensively with the "Request Deallocation" VI.  Perhaps it is freeing up memory to be reused within LabVIEW, but I haven't found a case yet where it decreases LabVIEW's overall memory size after VI execution (as viewed through Task Manager).  See the attached snippet, which I tested both running as a top-level VI and as a sub-VI as well as with and without "Request Deallocation".  In all cases, LabVIEW maintains its maximum memory usage (from when the queue is full) even after the VI is finished.

[playerm1]

I haven't had much luck with the request deallocation function either.  One thing that I have done in the past to help release memory from LabVIEW back to the OS is to call the memory-heavy VI asynchronously.  I believe that once the calling VI goes idle, LabVIEW will release any memory being held by the asynchronously called VI.  For your queue example, that code would be wrapped in a subVI and called by another VI asynchronously.  There may also be some nuance on how to initially configure the call; check out the term "reference ownership" for more info.

For VIs that may be storing large datasets within indicators/controls (like charts or graphs), make sure to clear those by settings their value to an empty array of their datatype when no longer needed.  That seems to also force LabVIEW to release memory back to the OS.

[Hooovahh]

Yeah anytime I've tried using deallocate memory to fix some kind of issues, the problem was just prolonged and the real issue was my software not being written to handle it well.

In the end just write code well, and don't worry too much about when memory is released.  Of the probably 50 times I've had memory issues with a LabVIEW application, probably 2 were actually because of a bug in LabVIEW not releasing memory, and the rest were all because of my code, or code I used, which wasn't closing references, or allowing for unbounded array sizes.  It is a higher level programming language and part of the benefit is being able to let LabVIEW do its thing.

[mcduff]

See this link along with the whole discussion to see what may be happening.

I ended up using DVRs to pass data around that was in arrays.

The memory can be cleared in them by writing an empty array to them before destroying the reference. See below.

Last step before destroying DVR, write empty array to clear memory

mcduff