request memory deallocation

[MengHuiHanTang]

One of the rules to improve better memory usage is to break VI into smaller subVIs, and memory usage improves because the execution system can reclaim subVI data memory when the subVI is not executing.

On the other hand, I found another statement (in the help file of 'Request Deallocation.vi') that 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 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.

These two statements are confusing. So what really happens to the subVI memory? Reclaimed or still allocated? If the subVI uses the same memory space over and over, what if it needs more memory next time it runs? Does LabVIEW  automatically deallocate the old memory space and allocate new one? or simply allocate new one and leave the old space there waiting to be collected?

The reason I ask about this is because I am having an 'Memory is FULL' issue. It is most likely due to the processing of large arrays. So I am wondering what happens to those subVIs who deal with the arrays when they finish executing. Do they release all the memory allocated to the large arrays? If they do, why am I still having an memory issue? It seems to me that memory was never released. So hard to debug this type of memory issue. 

[GregFreeman]

Without posting code, people are just going to be taking a stab in the dark at this one. I'm sure you hit the nail on the head, you are building too large an array. If you post your code, people can help you streamline it. Also, to your point of subVIs, if you are using unitialized shift registers to store arrays, you are basically creating a functional global which will keep your array in memory.

[MengHuiHanTang]

This is not really about any specific code. I am simply asking some general questions about how LabVIEW handles memory. 

[MengHuiHanTang]

Like you mentioned, the shift register will keep the array in the memory. Ok, what happens if I re-initialize the shift register with a new array of different size? It cannot use the old memory because size has changed; it will allocate new memory? What about the memory space for the last array? Deallocated immediately or stay? General questions like these. 

Thanks. 

[GovBob]

Have you gone through the LabVIEW perfomance and memory management guide? Maybe that will answer some of your questions.

Hope this helps.

[GregFreeman]

---

@MengHuiHanTang wrote:

Like you mentioned, the shift register will keep the array in the memory. Ok, what happens if I re-initialize the shift register with a new array of different size? It cannot use the old memory because size has changed; it will allocate new memory? What about the memory space for the last array? Deallocated immediately or stay? General questions like these. 

Thanks. 

---

Unfortunately your general questions have incredibly complex answers that depend on the implementation. I would suggest looking at the document attached in teh post above.

[smithd]

Hi All,

I don't have a whole lot to add past what For and Gov have stated, but I wanted to post this KB, which may help (especially, look at the related links):

http://digital.ni.com/public.nsf/allkb/A8BA755EB2A699FA86256FDC00691FFD?OpenDocument

You might also consider using the in place element structure, which is an excellent tool for memory management:

http://zone.ni.com/reference/en-XX/help/371361G-01/glang/in_place_element_structure/

Thanks,

D Smith

[Yamaeda]

---

@MengHuiHanTang wrote:

Like you mentioned, the shift register will keep the array in the memory. Ok, what happens if I re-initialize the shift register with a new array of different size? It cannot use the old memory because size has changed; it will allocate new memory? What about the memory space for the last array? Deallocated immediately or stay? General questions like these.

Thanks.

---

I would assume the compiler equals a reinitialization with 'new()' and allocate new memory.

However, Out of memory with arrays is usually 1 of 2 options:

1. The array need a too big continous memory slot, which can be solved in various ways (there was just recently a thread about big data sets)

2. Buffer copies. If the handling is sub optimal you'll create array copies which'll quickly fill the memory.

/Y

[Ben]

---

@MengHuiHanTang wrote:

One of the rules to improve better memory usage is to break VI into smaller subVIs, and memory usage improves because the execution system can reclaim subVI data memory when the subVI is not executing.

On the other hand, I found another statement (in the help file of 'Request Deallocation.vi') that 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 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.

These two statements are confusing. So what really happens to the subVI memory? Reclaimed or still allocated? If the subVI uses the same memory space over and over, what if it needs more memory next time it runs? Does LabVIEW  automatically deallocate the old memory space and allocate new one? or simply allocate new one and leave the old space there waiting to be collected?

The reason I ask about this is because I am having an 'Memory is FULL' issue. It is most likely due to the processing of large arrays. So I am wondering what happens to those subVIs who deal with the arrays when they finish executing. Do they release all the memory allocated to the large arrays? If they do, why am I still having an memory issue? It seems to me that memory was never released. So hard to debug this type of memory issue. 

---

Buffers are allocated to the wires as data flows and once allocated they keep the buffer. If the buffer is not large enough a new buffer is allocated and the data copied to the new buffer and the old buffer is retruned to LabVIEW who could re-use the old small buffer to another process.

I have never seen evidence that the buffers ae sized down once sized up.

Memory Full is a message saying that LV was unable to allocate a CONTIGUOUS buffer large enough.

Search this sire for "inplaceness" to read how to keep memory req, to a minimum.

The single large buffer can be addressed using (I bet the frequent flyers knows what comes next) Action Engines becuase they can work in a single SR buffer.

Other approaches that can help are

Multiple queues - the elements in a queue can be scattered.

DVR - work in-place by design

and TDMS (but that is an advanced topic that has not been fully tested)

Have fun,

Ben