TabView: Memory usage does not go down after opening/closing tabs

[lukeblevins]

It appears that there are invisible items in the WinUI TabView visual tree which stick around even after they are removed. This behavior isn't desirable because users could have many TabViewItems with memory-intensive pages as their content.

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Create a project where TabViewItems have a ContentTemplate property of a Frame with somewhat memory-intensive content.
2. Remove all of the tabs (hopefully destroying their content) by clearing the ObservableCollection.
3. Inspect memory usage to see persistently high levels

Expected behavior
TabView must support scenarios with robust XAML content inside the TabViewItems by freeing the memory when tabs are closed via removal from ObservableCollection.

Screenshots

Version Info

NuGet package version:
Microsoft.UI.Xaml 2.6.1

Windows version	Saw the problem?
Insider Build (22000.100)	Yes
May 2020 Update (19041)	Yes
November 2019 Update (18363)	Yes
May 2019 Update (18362)	Yes
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

Additional context
Old comment: #1332 (comment)

[ranjeshj]

@duke7553 can you see if this is resolved in the latest pre-release ? Do you happen to know if this regressed or something that is in older releases as well ?

[lukeblevins]

@ranjeshj Thanks for getting back to my issue. This has been an issue with use of TabView in our project for a long time. Probably since we switched to the WinUI TabView. Since this could very well be an issue with my app specifically, I am working on a sample project to demonstrate if the behavior is reproducible or not.

I expect to add it to this issue report soon.

[ranjeshj]

Thanks @duke7553 for the clarification. A repro app would be great.

[lukeblevins]

@ranjeshj This is a WinUI v2.6 sample app which reproduces the bug in a minimal way.

Download source code:
https://1drv.ms/u/s!AvgU7aa_XojBgYw8fAvMofoXYS6bfQ?e=LNGhL1

When running this sample, you should expect to see memory usage creep up quite a bit. Closing any tab will clear the collection and now you should see an absent/negligible decline in memory usage of the app.

[lukeblevins]

@ranjeshj @StephenLPeters I've updated the repro project for this bug to WinUI v2.6. The issue is definitely still present and it makes using the TabView for any kind of robust XAML content a nonstarter.

Please give it a look when you get a chance. 😔🙏🏻

[lukeblevins]

@ranjeshj @StephenLPeters I did some more detective work on this: It looks like this bug still exists even when completely replacing TabView with a regular ListView in my repro app.

Memory usage stays elevated despite clearing the ListView ItemSource. This includes setting it to null, removing each item one-by-one, and doing .Clear() on it.

Should this behavior be expected of Page and XAML controls in general with C#? How can I free an item's memory usage after it's closed? Am I missing something, or is this just an awful bug reported by many, other users over the years.

[StephenLPeters]

@duke7553 have you ensured that GC has run by calling GC.Collect() during your testing?

[lukeblevins]

@StephenLPeters Yes. The repro app does this after it clears the tabs

[lukeblevins]

Most of the memory growth is from unmanaged memory btw

[lukeblevins]

@StephenLPeters Is the team aware that this is an issue with TabView and ListView or is there something I'm doing incorrectly regarding coding practices with these controls?

[StephenLPeters]

It is on our radar, thank you for raising the issues.

[lukeblevins]

It was a recent fix so it will be included in a future release. Although, my understanding is the current plan is to service this fix, so some older versions of window 10/11 will receive the fix in a service update at some point.

@StephenLPeters Wow! Thanks for circling back and the transparency here. By any chance, would this fix already be present in WinUI Desktop? Or maybe UWP XAML is the only stack affected.

This made my day!

[StephenLPeters]

@RBrid do you know if the data template leak fix has made it into Winui3?

[RBrid]

@StephenLPeters, no I have not ported it to WinUI 3. No ETA for that unfortunately.

[lukeblevins]

@StephenLPeters @RBrid Has the OS fix shipped in Windows or the decoupled UI stack yet?

[ojhad]

We have made the fix but it has not shipped yet. We are working on porting it to WinUI3.

[lukeblevins]

@ojhad @RBrid @StephenLPeters Has this fix shipped yet?

[lukeblevins]

@ojhad @RBrid @StephenLPeters Should this be reopened?

[lukeblevins]

What a joke.

Hopefully this repository situation improves in the coming years, or else it's abundantly clear that WinUI isn't sustainable nor is it a priority to Microsoft.

[yaira2]

This issue appears to be affecting File Explorer and Notepad as well.

[0x5bfa]

@ojhad Has that fix been ported into WinUI3?

[neildmd]

@ojhad Has that fix been ported into WinUI3?

You would think that it would have been ported by now... This memory leak has been present for an embarrassingly long time. It's not like this is insignificant. Why are they dragging their feet on this?

[0x5bfa]

lol. Maybe they have been busy for a long time.
Do you think we should reopen? Looks like they have their mirrored issue tracker internally.

[codendone]

I checked with the team, and the fix has been in WinUI3 since WinAppSDK 1.3 (ported via internal bug).

It sounds like there are additional leaks beyond that fix. Please open a new issue with a repro for us to investigate those leaks. Thanks!