[MVU] Changing theme takes too long, ItemsRepeater seems to not dispose items ????

[kucint]

This one is tricky....

let's create a simple MVU model with the list state

internal record Item(string Text, Brush Brush);

internal partial record MainPageModel
{
    public IListState<Item> Items => ListState<Item>.Value(this, () =>
    [
        new Item("A", new SolidColorBrush(Colors.DeepSkyBlue)),
        new Item("B", new SolidColorBrush(Colors.DarkOrchid)),
    ]);
}

Let connect the list state to the view:

    new ScrollViewer()
    .Content(
        new ItemsRepeater()
        .ItemsSource(() => vm.Items)
        //.Layout(new StackLayout())            // this is virtualizing layout
        .Layout(new NonVirtualStackLayout())    // this is non-virtualizing layout
        .ItemTemplate<Item>(item => GetItemView(item))
        )

    private static Grid GetItemView(Item item) => new Grid().Children(
        new Rectangle()
        .Width(100)
        .Height(20)
        .Stroke(Colors.Black)
        .StrokeThickness(1)
        .Fill(Themes.MyBrush)      // themes binding
        .Margin(3),
        new TextBlock()
        .Text(() => item.Text)
        .VerticalAlignment(VerticalAlignment.Center)
        .HorizontalAlignment(HorizontalAlignment.Center)
        .Foreground(() => item.Brush)
        );

Please note the Themes binding used in the item

internal static class Themes
{
    public static readonly Resource<Brush> MyBrush = ThemeResource.Create<Brush>(nameof(MyBrush),
        new SolidColorBrush(Colors.LightBlue), new SolidColorBrush(Colors.LightCoral));
}

This app works like a charm with both virtualizing layout and non-virtualizing layout:

The app allows to add more items to the list and switch the light/dark mode. All good.

Issue 1

When a number of the items grows, the time of theme switch takes surprisingly very long time: with 2000 items created it takes more then 10 sec (debug).
The long execution time is observed only on non-virtualizing layout. On virtualizing layout, the switch is quick (obviously)

Issue 2
if a significant number of items have been added (~2000) and then all of them are removed (items count is again 0) I would expect that the theme switch is again quick but this is not a case. it takes exactly the same amount of time as all 2000 items would still exist.

I do not understand why it so, but it seems to me, that somehow removed items still persist and influence the app.
No idea if it has something to do with Themes, ItemsRepeater, MVU state update or any combination of these.

If items remain indeed undisposed, this issue would be hidden when using any of virtualizing layout...

Remarks:

• It is maybe obvious, but ..... if you comment out the theme binding line: // .Fill(Themes.MyBrush) than switching theme is again quick, so the issues have nothing to do with the number of items being rendered.
• NonVirtualStackLayout class has been copied from uno unit tests: Uno.UI.RuntimeTests\MUX\Microsoft_UI_Xaml_Controls\Repeater\Common\NonVirtualStackLayout.cs
  so I assume it is rather not the cause of problems here...

repro: UnoThemeTooSlowApp.zip

[kucint]

Please conduct following experiments:

Experiment 1

1. run the app
2. add 3000 elements by clicking 30 times "Add 100 items" button, check application memory usage
3. click "Clear" button and check application memory usage
4. go to point 2
5. repeat in loop and collect application memory usages in each evolution

The result of the test is following on my computer:
First number represents memory usage after adding 3000 elements, the second one after removing all items
Memory usage in MB:

0 114     -> memory usage after app started (release mode)
1 325 325 -> memory usage after "add 100 items" clicked and after "Clear" clicked
2 347 342
3 359 360
4 380 380
5 392 394

Test performed in release mode, no debugger attached.
Test in Debug mode with/without debugger behaves similarly.

As you see, memory usage always grows, never shrinks.
It is ok that is does not shrink, but it should not grow in infinity. memory usage should quickly become stable ....

Experiment 2

1. run the app
2. check initial application memory usage
3. add 3000 elements by clicking 30 times "Add 100 items" button, check application memory usage
4. maximize app and check application memory usage
5. restore app and check application memory usage
6. wait 1 minute and check application memory usage
7. go to point 2
8. repeat in loop maximize/restore/wait and collect memory usages in each evolution

The result of the test is following on my computer:
First number represents memory usage after maximize, the second one after restore, the third after wait
Memory usage in MB:

0 187          -> memory usage after app started (debug mode)
1 378          -> memory usage after "add 100 items" clicked
2 433 469 450  -> maximize, restore, wait
3 501 524 501
4 544 565 542
5 510 503 461
6 495 501 472

As you see, memory usage grows consequently, it shrinks as well a bit, but is far away (100 MB) of memory used when items have been shown for the first time.

Important

I guess that, items are not properly disposed.

Please note, that this test has been performed on newest build: 5.4.0-dev.93 which contains already a fix for #2404

[MartinZikmund]

@Youssef1313 will investigate whether there could be leaks happening in ItemsRepeater directly

[Youssef1313]

[MartinZikmund]

@dansiegel Youssef investigated the performance aspects on Uno core side, but it seems the memory leaks come from C# markup. Can you please investigate this? Turned this into issue - #2428

[MartinZikmund]

Will close this discussion in favor of #2428