Memory Leak

Hi Clint,

Thanks for telling us about this.  After doing some quick testing, I believe the documents are persisting in memory, even after being closed.  There isn't a good memory profiler yet for WinRT but we will do our best to track down what is holding onto the references.  We'll let you know what we find.

Hi Clint,

We've put quite a few hours into researching this more.  The main problem is that there is no good tooling at the moment for detecting memory leaks in WinRT.  One available tool is PerfView from Microsoft, and it doesn't give much useful info at all.  We contacted the company that makes the normal .NET memory profiler we use and they have a WinRT-compatible beta version coming in several weeks.  We are on the list to get that.  We also found that JustTrace recently added some memory profiling for WinRT, and while it's not nearly as good as the other normal tool we use, it's better than PerfView.

At least what we can glean from these tools is that might be running into the property changed events not getting released from our page view models.  We found this Connect bug that someone else filed on a similar issue, which seems to be a bug in WinRT:

http://connect.microsoft.com/VisualStudio/feedback/details/761770/metro-apps-with-c-heavily-leaking-memory

That may be part of the reason our document instances build up over time.  We've changed some things internally that might help with the scenario.  There still seem to occasionally be objects held that both tools indicate are being held from within WinRT (not our code) and we're not sure how to handle those random scenarios.  Even when this happens though, we've made updates to minimize the amount of held memory.

Our internal updates will be in the next version.  We will look more in depth again once we get the new version of .NET Memory Profiler that supports WinRT.  If you continue running into the sluggishness, you may need to occasionally close down the app and restart it.