Cleaning Up Closed DocumentItems (ViewModels)

Hi Justin,

Using task manager isn't really a proper way to watch for .NET memory leaks.  You need an app like the one at memprofiler.com that can watch all .NET references and tell you which ones are actually held, if any.

For instance, if I run our MVVM DocumentWindows sample and take a memory snapshot on its intial state, the .NET Memory Profiler tells me I have one instance of ImageDocumentItemViewModel and two instances of TextDocumentItemViewModel.  When I close each document and take a new snapshot, I see those live instances are removed (as expected).  From that I can see, there's nothing on our end that retains a reference to those view models.

It could be that what you are seeing is that the .NET GC is waiting to collect the memory formerly used by those live instances.

>>Using task manager isn't really a proper way to watch for .NET memory leaks. You need an app like the one at memprofiler.com that can watch all .NET references and tell you which ones are actually held, if any.

I know - I've tried using the JetBrains memory profiler. The problem is that it's not a purely .NET application - it references many C++ dlls, uses DirectX, and other types of memory that such a profiler doesn't see (aka memory that isn't handled by the .NET GC). Thus, I need some sort of reference for what's going on overall, even if it isn't as foolproof/ironclad/accurate as a profiler would be, if it were a purely .NET application.

So in the case of the task manager, I'm pretty familiar with how it behaves for "non-leaky" applications; the memory usage doesn't directly reflect what's going on from moment to moment, because as you say the GC may take awhile to run, etc. That's to be expected. For example, memory may grow and grow for a bit, but eventually you'll see it jump back down, usually settling within some range. However, in this case, I can actually repeatedly open & close a tab and watch the memory usage climb until it exhausts the system's 8GB (one tab for a large document may use ~100MB). It never really decreases - clearly a very different behavior, and indicative that something isn't right (beyond the GC just not running) :/

Hi Justin,

Unfortunately I'm not sure what to tell you in that regard unless you can show with a .NET memory profiler that we are somehow maintaining some .NET references on our end.  It doesn't appear to be the case though based on the tests we've done.  But if you do see otherwise, we are happy to look into a sample you can provide that would show us causing a managed memory leak and we can make appropriate code updates to help.

Alright, understood - I guess I was just curious if anything else needed to be done on my end to make sure the VMs would be freed (other than the library's existing fully automatic handling of closing the tabs).  I guess the answer is that it shouldn't, so I'll have to start debugging on my own.

Thanks~

Hi Justin,

You shouldn't need to do anything else on your end, at least in terms of VM usage with Docking/MDI. Once the related docking window is destroyed (meaning removed from being tracked by the DockSite), we no longer maintain a reference to the docking window or the VM.

The only thing you might really run into is if some control you use within the DataTemplate for a VM content display is attaching to events, etc. higher up in the visual tree and never letting those go, even after the docking window is destroyed. But that would be something done purely on your side if you are doing it.

Understood - thanks for the thoughts :)