request deallocation

[PaulG.]

I understand LV "manages" it's own memory. So what is the purpose of the request deallocation vi?

[Norbert_B]

PaulG,

i copied an extract of the LabVIEW help for this vi:
Deallocates unused memory after the VI that contains this function runs. 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. Place the Request Deallocation function in the subVI you want to deallocate memory for.
i think, this is quite self-explanatory.

Norbert B.

[PaulG.]

Thanks. I generally read the help files before posting. I'm still not clear just when I should use the request deallocation. No one has been able to give me a clear and definitive reason as to when I need it or not. LV memory management is quite complex and has improved considerably with each new revision. I've also been told that request deallocation is used "rarely". I have a large application with subvi's 10 levels deep. Some (uninitialized shift registers) are called and released on numerous occasions before the calling vi closes. Do I need to use a request deallocation in each sub vi? Which ones? I guess what I want to know is if there is a performance issue with using the request deallocation or not. Or if a vi is called and released on numerous occasions does the calling vi allocate a different part of the memory every time it is called? I would rather be safe and just put it everywhere, but that wouldn't make sense if LV managed it's own memory.

[Norbert_B]

PaulG,

lets look on memory allocation in LV first. a very important hint is contained in my quoted help-file.
"When a top-level VI calls a subVI, LabVIEW allocates a data space of memory in which that subVI runs". this is true for EVERY vi, but there can be two different settings, which affect the freeing of the memory: reentrant and non-reentrant. non-reentrant vis are the "normal" case and reuse the same data space. reentrant vis allocate new data space each time it is called from a different place.
now to the "request deallocation" vi: first of all, as already included in the name: this is only a request. if memory is deallocated at all depends on your subvi.
another point is, that the data space itself is NOT deallocated with this vi. you can make a short test on your own with a subvi which uses an uninitialized shiftregister. so what does this vi do at all?
the help-file states that "unused memory" will be deallocated. what is "unused"? this is a bit tricky. i asume that unused memory is memory allocated during the execution which is not initially part of the data space. in general, these memory is allocated by working with strings and arrays.

hope this clears things up a bit.

Norbert B.

[PaulG.]

Thank you. That clears it up quite a bit.

Paul

[falkpl]

Labview is a managed memory language which makes programming very easy but you do loose some fine control over the process.  An analogy:

Imagine used memory like garbage.  You place the trash (no longer needed allocated memory) on the curb every night, in an unmanaged system this will build up until there is no more space on the curb (out of memory error/slow system response/ crashes).  In c++ and other unmanaged languages when you allocate memory you must explicitly free it, memory is a finite resource so if you use a lot of make sure you return it.  So in an unmanaged system you must take the garbage to the local dump (deallocate used memory), this is a tedious task best left up to a trash collection service.  This is where managed systems like labview (java and c# do this but LV did it many years before it became cool to be managed).  Labview has a garbage service which will periodically pick up your trash so it doesn't build up.  So you wonder "Why request deallocation?".  Lets say you had a party last weekend and you have 10 huge bags of garbage which you put on the curb.  Garbage services don't come till Wednesday, so you call up for a special pickup to collect the excess trash.  I use the request deallocation for the same instances: a subvi which uses a huge amount (large arrays) for temporary processing and are called often, you can deallocate memory after such calls explicitly.  If you notice that your application seems to slow after many repeated calls, it can help to let LV know you wont need the large chunks of memory a subvi needed for temporary buffers.  I don't know the inner workings on LV garbage collection but I found that the request deallocation has helped me out of a few difficult situations.  As far as deallocating memory while a vi or subvi is still running (like is possible in c/c++) I haven't figured out how to do it if it is even possible.

Paul

[falkpl]

A few additional questions on deallocation:

1.Is there overhead associated with the request deallocation?

2.If deallocation is essentially a Boolean state of a subvi/vi why isn't it set using the property node (or better yet through a setting under vi->properties), this would seem to fit better under LV's data-flow model.

3.Are there any times where setting request deallocation causes problems with LV, any known bugs? (platform independence)

I know this is a little used feature, I haven't had problems with it ever but am very reserved when using it.

Paul

[Philip_Courtois]

Hi Paul,

The main reason that unused memory in subVIs is not automatically deallocated automatically until the program stops, is because it's more efficient to keep the memory available if the subVI is called again and the memory is accessed. For example, if you call a subVI 1000 times that uses a large array, not deallocating the memory will simply reuse the memory space and therefore be extremely efficient. By deallocating the memory every time, the array will have to be allocated and then deallocated 1000 times - which is not an efficient process, mainly due to the allocation.

Your idea about placing the deallocation feature in the VI Properties sounds like a valid idea. You should submit this as a Product Suggestion using the "feedback" link from www.ni.com/contact.

Thanks.

[falkpl]

Philip,

Thanks for the clarification about reusing data memory on subsequent calls of a vi.  What happens if you need a different size memory space on each call, can this memory be reused, I assumed that only static sized memory variables can be reused, but I could be wrong.  If you can not reuse memory space for certain cases then repeitive calls to such a vi would have to free memory as to avoid a memory leak.  Is this still the case?

Paul

[Philip_Courtois]

Hi Paul,

Well, the size of your data in the SubVI will change as you re-initialize it. For example, if your SubVI is using a shift register to dynamically grow an array, the memory space for the array is not deallocated until you re-initialize the shift register. However, if you do not re-initialize or resize the array, the memory will not be deallocated unless you quit LabVIEW or call the Request Deallocation function.


Have fun - and more of it with LabVIEW 8!