Why do I have to remove VI from SubPanel?

[CoastalMaineBird]

TST - I ran your example and yes, it's obvious that the HELP is incorrect.

You can STOP the SUBPANEL.vi, but the subVI remains within the SubPanel.

[CoastalMaineBird]

OK, so I restored it to CALL and COLLECT, and REMOVE the VIs on closing.

Here's my memory usage, using the stress-test.

there are four of these windows, the stress test does OPEN 1, OPEN 2, OPEN 3, OPEN 4, CLOSE 1, CLOSE 2, CLOSE 3, CLOSE 4.

It takes its time about releasing the memory, but it does get there.

If there is a leak here, it's very small (compared to the 100 MBytes before).

I still don't understand things though. 

Why do i have to remove the VI?

Why does CALL and FORGET make a difference?

[CoastalMaineBird]

So, now that the memory leak is stopped, why does it take so dang long to remove the VIs ? ? ?

Here's an excerpt from the log file:

075265 - Waited 14706 mSec on Closure
075604 - MMM: Close Unit 1
082740 - MM Unit 2 Block 2 Queue Event.
082740 - MM Unit 2 Block 0 Queue Event.
085715 - Waited 10104 mSec on Closure
090654 - MMM: Close Unit 2
096840 - Waited 6180 mSec on Closure
105708 - MMM: Close Unit 3
108091 - Waited 2380 mSec on Closure

This is with all four windows up (that means there are 288 instances of the BLOCK VI running).

It takes 14.7 seconds to remove 72 out of that 288 ?

It takes 10.1 sec to remove 72 out of 216 ?

It takes 6.2 sec to remove 72 out of 144 ?

and it takes 2.4 sec to remove the last 72 ?

It's almost like it has to search through the whole list to find each one.

Without the REMOVE VI, the time for closure is 300-500 mSec.

[CoastalMaineBird]

If I, instead of REMOVE VI at closing time, put the SubPanel into a queue, and perform the REMOVE VI in a new VI which watches that queue, the CLOSURE time decreases, but the MEMORY LEAK returns.

IOW, I have to REMOVE THE VI at the point of closure to avoid the leak.

I don't understand that, either.

[tst]

---

CoastalMaineBird wrote:

I still don't understand things though. 

Why do i have to remove the VI?

---

Presumably same reason as before - I'm assuming the caller stays in run mode (and yes, that's the same thing as reserved, although it also encompasses the executing state). If that's the case, then just stopping the caller or the subVIs doesn't cause their FPs to close.

I don't have an answer on the performance issues, since I don't have any experience with call and collect calls and not much experience with working with many subpanels. Looking at one example where I do have many SPs (>100), though, shows that completely stopping the caller (which includes removing all the VIs from the SPs) takes less than a second. That's a fairly simplistic example and it uses the old "open reentrant VI and call the Run VI method" routine.

If you have some performance issues to pinpoint, disabling parts of the code or creating clean VIs which only contain the relevant parts seems like a reasonable move.