Repository navigation
Memory retention issue persists after setting DataGrid to "null" #4986
Description
Describe the bug
I'm currently using the CommunityToolKit DataGrid in my application. Upon adding the DataGrid through a button, I observed that the application's memory usage increased from 98MB to 108MB. However, even after setting the DataGrid reference to null upon button click, the memory usage remains at 108MB instead of reverting back to the initial 98MB.
Additionally, I need confirmation on the proper method to dispose of the Community DataGrid. Is simply setting the DataGrid reference to null sufficient, or are there additional steps that need to be taken?
Regression
No response
Reproducible in sample app?
- This bug can be reproduced in the sample app.
Steps to reproduce
1.Run the sample
2.Watch the process memory in the Diagnostic Tools.
3.Click Add Datagrid button.
4.Repeat step 2.
5.Click Dispose button.
6.Wait for few seconds and repeat step 2.
Expected behavior
My goal is to ensure that after setting the DataGrid reference to null, the application's memory usage returns to its original level of 98MB.
Demo Sample - DataGrid_Demo.zip
Screenshots
Video reference - DataGrid_MemoryConsumption.zip
Windows Build Number
- Windows 10 1809 (Build 17763)
- Windows 10 1903 (Build 18362)
- Windows 10 1909 (Build 18363)
- Windows 10 2004 (Build 19041)
- Windows 10 20H2 (Build 19042)
- Windows 10 21H1 (Build 19043)
- Windows 11 21H2 (Build 22000)
- Other (specify)
Other Windows Build number
Windows 11 23H2 (Build 22631.3447)
App minimum and target SDK version
- Windows 10, version 1809 (Build 17763)
- Windows 10, version 1903 (Build 18362)
- Windows 10, version 1909 (Build 18363)
- Windows 10, version 2004 (Build 19041)
- Other (specify)
Other SDK version
No response
Visual Studio Version
2022
Visual Studio Build Number
No response
Device form factor
Desktop
Nuget packages
CommunityToolkit.WinUI.UI.Controls.DataGrid Version="7.1.2"
Microsoft.WindowsAppSDK Version="1.5.240404000"
Microsoft.Windows.SDK.BuildTools Version="10.0.22621.3233"
Additional context
I am facing this issue in the older versions of the SDK too.
Help us help you
Yes, I'd like to be assigned to work on this item.
Activity
KamuJeong commentedon Mar 8, 2025
I have been using same DataGrid and recently recognized same issue.
After struggling with it for a week, I found reasonable bugs and solution.
There are two misused patterns in source code.
hmm... But in fact, it seems to be one.
First, WeakEventListener is not weak.
It's a snipet in DataGridDataConnection.WireEvents().
The handler to OnDetachAction event should be a Closure which refers to this DataGridDataConnection object through notifyingDataSource1 local variable. Because this DataGridDataConnection refers to DataGrid itself, GC will never reclaim DataGrid object if you don't call UnWireEvents() explicitly (or implicitly like changing ItemsSource to null).
Second, DispatcherQueueTimer is weired
In DataGrid.HideScrollBarsAfterDelay(),
Tick event also gets a Closure handler which refers to DataGrid itself, and DataGrid keeps a reference into the DispatcherQueueTimer object by _hideScrollBarsTimer member field. i.e. it's a typical circular reference case.
In general, the circular referencing is not wrong, GC is sufficiently capable in such case.
But, this is not the case. it seems like DispatcherQueueTimer object does never die.
The solution is the breaking circular reference. Dereference timer or detach the handler.
Ok, it's all.
I finally call DataGridDataConnection.UnWireEvents() and dereference DataGrid._hideScrollBarsTimer field with null using Reflection.
So far, I'm happy.