Memory Usage Constantly Increases

[lukeblevins]

Please download the latest snapshot, and check the memory usage from opening and using more tabs.

• Does the RAM usage decrease when tabs are closed?
• Does memory usage ever decrease to normal levels after loading a large directory? (~500-1000 items) Tip: Try to load C:\Windows\System32
• If you answered NO to any of these, are you willing to help me investigate a fix?

I'll be eagerly awaiting input on this topic.

[GitMoDu]

I compiled and ran locally the NEW-UI branch. I get ~50 MB at start and ~10 MB per tab, without any other interaction.

[lukeblevins]

@GitMoDu Does this memory usage decrease after the tabs are closed?

[GitMoDu]

Nope, I don't even see the GC firing, you must be holding on to some reference that prevents dealocation.

[lukeblevins]

@GitMoDu Yep. I noticed even when I force a GC, almost nothing occurs.

[lukeblevins]

@ashikns If you have the time, it would make me really happy to get your help with this. The work is being done in the newui branch, or you can optionally download a snapshot.

[ashikns]

I'm a bit time constrained at the moment, but I'll try and take a look over the weekend.

[ashikns]

Also, you probably already know this but just in case: forcing a GC won't free memory if there's a reference to it. These days UWP apps are pretty intelligent about memory management so manual GC is rarely needed.

[ashikns]

I got some time to investigate this today. Unfortunately I haven't been able to fix it, however I found some info that could be useful.

First off, to test I modified the add tab button to add 100 tabs at once, and also added a button to clear all tabs. Plus I also added a list to ProHome.xaml.cs that gets populated with a million random ints. These steps were done to make the memory issue pop up reliably without much effort.

The test machine has 32 gigs ram and has ~30% ram load while testing (Chrome sits at top with 1.5 gigs usage -_-). GC collection is triggered after the app uses ~800 mb ram. This number will vary based on 2 factors:

1. How much free ram you have
2. Memory usage pattern of your app - for example with my modifications above the usage pattern becomes "consume ~500 mb within 5 seconds, then release it". With this pattern each time you consume a large amount of memory in a short span CLR tries to keep that memory in the heap because it assumes you might need that memory again very soon. What this all means is that app ram usage can go higher and higher - it does not necessarily mean there's a leak. What you have to look for is whether the GC collection happens or not. I do this by adding a finalizer to the class I want to monitor and putting a Debug.WriteLine inside it. There's probably a better way to do this using profiler.

Now coming to the issue itself. Briefly put, the problem is caused by lines 537-611 in ProHome.xaml (xaml, not the xaml.cs) as of commit cb67820. The combination of TabView, TabViewItem, CommandBar and AppBarButton seems to lock the objects in memory somehow. If you comment out the CommandBar sections inside the TabViewItems the problem is solved. Note that I only investigated this. There maybe other memory leaks due to event subscription and what not, but this one seems to be the main one.

I have no idea why this happens though. It's been ~4 years since I last dealt with xaml and that was back in the prime days of wpf, and it was never my area of expertise. I'd suggest you replace it with an alternative from the UWP community toolkit or something that you have source code available. At least then you can step into the source and see what's broken. Try it out and if you can't fix it post your findings here, I'm sure someone from the community has some idea (or I can tackle it again later).

Oh and one more note: make sure your scrollviews are virtualized. Maybe UWP does this by default, in wpf you had to enable it manually.

[lukeblevins]

@ashikns Thank you for this. Maybe I could replace the command bars with a StackPanel containing buttons. I wonder if it is just the TabView control that doesn't allow for its item's content to be garbage collected when closed. I will test this out, and report back.

[lukeblevins]

@ashikns I now notice this may be a bug with the TabView control because I can reproduce the memory leak with apps that don't contain CommandBar as TabView content. Meaning, regardless of what is assigned as TabView content, it stays in memory after closed.

[GitMoDu]

Interesting, I only ever used TabView in a momentary panel (reused for the entire lifcycle), so I would never find such a bug.

[ashikns]

@duke7553 that makes sense. TabView is from the open source UWP toolkit right? Might be a good idea to take a look through their issues and open a new one if it's not yet there.

[lukeblevins]

Here is the issue report I filed the other day: CommunityToolkit/WindowsCommunityToolkit#2938

Hopefully they take it seriously

[lukeblevins]

@ashikns @GitMoDu I figured out this behavior only occurs when adding TabViewItems manually rather than generating them from a data source. The unfortunate part is, I can't change it to that method because the TabView control doesn't allow me to set the individual tabs content from the data source. I filed another bug to track this: CommunityToolkit/WindowsCommunityToolkit#2946

Thanks for your help, guys.

[lukeblevins]