deallocation of memory for subvis

[Garvacious]

I have never been able to successfully get the "request deallocation" function to work in LV.  It really does seem like a "placebo" function.  Has anyone actually successfuly gotten this to release subvi memory after the subvi is no longer running? 

[smercurio_fc]

Yes.

[smercurio_fc]

(Coming back a few minutes later)

OK, now that I had my fun... perhaps your memory usage is stored up in indicators. Just because the VI is stopped, that memory doesn't get deallocated. If you provide more information about what your VI is doing, then a more specific response can be provided.

[Garvacious]

Hmmm...so memory stored as front panel controls/indicators does not get released by the deallocate memory function?  That seems odd....is there a way to release the FP memory?

I have been working on a LARGE app that has many subvis/panels that dynamically launch and close- but once LV allocates that memory it really is stingy about holding onto it.  That is fine for most apps that have a few panels, but this one really needs a way to conserve memory as people open/close various panels with lots of indicators.

[Ben]

"Back in the day" of LV 6i when we drew our diagrams on stones... the deallocate acted when called. That was misreable for performance so it was changed.

The "deallocate" only works on VIs that are idle and the refs closed.

SO you have to unload the dynamic Vi if you want its memory reclaimed.

Controls and indicators current values default values etc will be saved if you use "save as default" and then save the VI. Otheriwse those buffers get released when the VI owning them goes away.

Ben

[Garvacious]

Ah yes the "LabVIEW 6 (internet edition)" days.  

So, it appears placing the deallocate function anywhere on the BD is fine- that will trigger LV to release that vi's memory when unloaded (and all references to it closed)?

[altenbach]

If you are worried about the memory use of front panel indicator/controls, you have a couple of options:

• Make sure that the front panel is not in memory! (this means don't have the front panel open and don't use code that forces it to be in memory (e.g. property nodes).
• Make the subVI subroutine priority. This prevents updating controls and indicators even if the panel is shown (pretty useless to show the panel in this case).

Also make sure that the subVI does not have huge amounts of default data.

Overall, we need to see some code to decide where the problem really is....