Request Deallocation?

[jyang72211]

I am looking at a couple of subvi that pull and process a large 2d array.  At the end of each subvi, the Request Deallocation is used.  Is that neccessary?  Is it a good practice?

[SteveChandler]

Only if you never plan to use the data memory space again. LabVIEW will eventually deallocate the memory but it may not be sure if you need it again so it might take a while. If you know you are done with the allocation then call it to immediately release the resources. If you request deallocate and do in fact need it again then your performance will suffer because the memory has to be reallocated.

[GuenterMueller]

To my opinion, the deallocation makes sense because several VIs deal with large 2D-arrays.  Request Deallocation should minimise the risk of getting out-of-memory rrors in LabVIEW.

[jyang72211]

There is only 1 large 2d array.  All the subvi are using the same array.  When a subvi is done using the array, the subvi would deallocate the memory.  Thus, when the next array needs it again, the memory has to be allocated once more. Perhaps, he did this to make sure that only one memory space is allocated for that 1 2d array  My question is

How do I prevent labview to allocate mulitple copies for the same array when the array is being passed in and out of different subvi? 

If I have a state machine, and each state would have subvi that access the array through the shift register of the main state machine.  Would the shift register of the main state machine and all the subvi have a copy of the same array in memory?  If I have 3 states with subvi plus the main state machine with shift register, would I have 4 copies of the same array in memory? 

Thanks!

[SteveChandler]

The memory allocated for a subVI will be deallocated when the top level caller goes idle. If you are calling a subVI in a loop you almost definitely do not want to explicitly deallocate.

[jyang72211]

What do you mean by when the caller goes idle?  Does that mean when the caller is not idle, there would be multiple copies of the same array for different subvi that needs it? 

[GuenterMueller]

---

@jyang72211 wrote:

[...]  My question is

How do I prevent labview to allocate mulitple copies for the same array when the array is being passed in and out of different subvi? 

---

Passing data in and out usually does not force LabVIEW to copy the data: You can verify with   Tools >> Profile >> Show Buffer Allocations...   that LabVIEW reuses the data on the wire and no copy will be made -> This is no use case for "Request Deallocation".

---

jyang72211 wrote:  [...]

If I have a state machine, [...]  If I have 3 states with subvi plus the main state machine with shift register, would I have 4 copies of the same array in memory?

---

It depends on how the subVIs are allocating buffers.  Again, use Show Buffer Allocations...  in all subVIs. If no allocations take place, you do not have to worry. On the other hand: If you are unsure if the subVI allocates a buffer (e.g. because you might make a small change to it that forces LabVIEW to copy and you do not consider this at wiring time), you could place a "Request Deallocation" on the subVIs block diagram.  If there is a chance to free any memory, LabVIEW will do so when this VI finishes.  If there is nothing to deallocate -> "Request Deallocation" should be merely a "no operation".

[SteveChandler]

---

@jyang72211 wrote:

What do you mean by when the caller goes idle?  Does that mean when the caller is not idle, there would be multiple copies of the same array for different subvi that needs it? 

---

I just mean that the run arrow is ready to be pressed again. Deallocation does not have anything to do with the number of copies. If you have a subVI that creates a very large memory allocation, and you know that it is no longer needed, then deallocation can free up unused memory. But if you do end up needing the memory again that was already allocated then it is a performance hit.

[GuenterMueller]

---

@Steve Chandler wrote:

---

...] But if you do end up needing the memory again that was already allocated then it is a performance hit.

---

Right you are, Steve. Let's keep in mind that jyang72211 did not complain about this. He did not mention any out of memory errors, either.  I hope that he feels well informed about Request Deallocation.

[SteveChandler]

Right, I just wanted to clarify.

To clarify even further using an example, request deallocation is kind of like telling your landlord that you are moving out. They can then rent your place to a different tenant. But you only do this when you are not going to return. You wouldn't do this every time you go to work and then rent a different place after work. There is lots of overhead in getting the lease. Finding a place, rental applications, credit checks, deposits, first and last month's rent, moving furniture, etc.

If you are going to work then it is going to be very wasteful of resources if you move out and rent a new place after work. Only tell your landlord you are done with your place if you really don't want it anymore. That is request deallocation. (Hopefully it isn't a stupid example)