Cleaning Up Closed DocumentItems (ViewModels)

Docking/MDI for WPF Forum

Posted 2 years ago by Justin Klein
Version: 17.1.0650
Avatar

This is a follow-up to this thread: http://www.actiprosoftware.com/community/thread/23221/mvvm-closing-doesnt-remove-from-documentite#111265

I'm now using vNext, and the DocumentItems list does stay "in sync" with the document tabs when they're closed.  However, I've observed that the actual ViewModel objects don't seem to be getting cleaned up / garbage collected; if I open a doc, close its tab, open a doc, close its tab, etc - the DocumentItems collection does cycle between 0 & 1 as expected/desired, but in the Windows task manager, I observe the application's memory usage growing without bound.  Is there somewhere that I need to explicitly remove/free/destroy/cleanup/etc the ViewModel, to prevent such a leak?

Thanks again

Comments (6)

Posted 2 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 2 years ago by Justin Klein
Avatar

>>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) :/

Posted 2 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 2 years ago by Justin Klein
Avatar

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~

Posted 2 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

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.


Actipro Software Support

Posted 2 years ago by Justin Klein
Avatar

Understood - thanks for the thoughts :)

The latest build of this product (v2018.1 build 0675) was released 1 month ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.