request deallocation function with reentrant clones

[chiraldude]

I have a standalone application (Labview version 12) that is processing very large chunks of data. Each batch run can take hours to complete.  I am storing all intermediate data in files to avoid running out of memory but still I am having occasional issues of running out of memory.  I never have an error on the first batch, only on the 2nd or 3rd.  I am experimenting with using the request deallocation function at the end of each batch but I am not clear on how/when it takes affect.

There are 2 sub VIs that do all the work so I have placed the request deallocation in these with a boolean input to be true the last time it is called.  After the last call, the main application is idle waiting for the user to request another batch so this seems like the logical time to deallocate. These subs are configured as shared clone reentrant. They also have subs 2-3 levels deep.  How does the request for deallocation take effect for reentrant VIs?  Are all clones deallocated or just one?  What about VIs called within a deallocated sub? Are they included in the garbage collection or does each sub VI called have to be deallocated seperatly?

[Yamaeda]

As i've understood things, request Deallocation is basically "do garbage collection now". If you have references/data arrays in use it cant be thrown away yet.

If it works the 1st time, but you get problems the 2nd or 3rd it sounds like you're growing some arrays or making data copies.

Can you post the VI?

/Y

[chiraldude]

Hear are a couple of screenshots of the code in question.

The Save CSV Data vi is called a number of times to reformat a very large set of csv files (first image).   When the loop is finished, the last call does nothing but sends a True value to the deallocate function.  Inside the Save CSV Data vi (second image), that 3D array of strings being saved to file is a likely memory hogs and I am hoping to be able to deallocate it.

[FmTesla]

Hi chiraldude

I think that if the SubVI is not dynamic, (being part of the application) it will be keep in memory while the top level VI is running. If you load the VI dynamically, the deallocation will be done when all references are closed.
The last time I poked around with the de-allocate, it only cam e into play when the VI in question was marked for removal from memory. If the sub-VI is part of the app (not dynamic) it will not be marked for removal while the top-level VI is running.

However, I would like to recomen another tool that might come in very handy with this case, the place element structure.

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

Regarding memory administration, this links might be useful as well

 How Can I Optimize the Memory Use in My LabVIEW VI?

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

Determining When and Where LabVIEW Allocates a New Buffer

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

Warm Regards