Horrible performance/memory usage with CollectionView depending on size on screen

[feal87]

Description

I'm developing a small personal app and I decided to try and use MAUI with XAML for it.
It seems like CollectionView (ListView too, tried myself) has some huge issue in performance and memory usage that depends entirely on how big the collection is on screen when scrolling.

Both videos are run on a release version of the app with an i5-10300H as processor on a laptop.

See below video when the collectionview is big.
https://user-images.githubusercontent.com/26706898/206872000-158e0edd-bd07-4826-9a45-a2e10a07562f.mp4

See below video when the collectionview is medium size
https://user-images.githubusercontent.com/26706898/206872003-4d127e55-dc7c-479b-b5a7-6a077df8566a.mp4

It gets even worse when the collectionview is even smaller.

I'm assuming it's choosing how much to cache based on the size of the item on screen and I have not found any way to override that.
Am I doing something horribly wrong? I can't seem to understand how such a simple app can basically destroy a new machine just scrolling a list of items. Even a browser app can do better than this...

Steps to Reproduce

Open public reproduction project repository and press run. Try to scroll quickly the grid.

Link to public reproduction project repository

https://github.com/feal87/ReproductionTest.AppForMAUI

Version with bug

7.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

Windows SDK

Did you find any workaround?

No response

Relevant log output

No response

[Vroomer]

Wrap the DataTemplate of CollectionView in Border. There is a bug that prevents proper view recycling otherwise: #10560

[Quietscheente]

Isn't grid's row and column index starting with 0?

<Grid.RowDefinitions>
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <Border Grid.Row="1"  ...
...

[feal87]

Isn't grid's row and column index starting with 0?

<Grid.RowDefinitions>
            <RowDefinition Height="*" />
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>
        <Border Grid.Row="1"  ...
...

I just extracted the code from my application for the test and deleted all the unrelated rows/columns, but forgot to update the remaining Rows. it doesn't really matter though even if you change it.

Vroomer, your change works as a workaround but of course that affects the layout. Hopefully there'll be some work on it...

[Quietscheente]

Ah, ic.
Just to exclude that this index affects the performance

[jfversluis]

Hi there, thanks for the report!

I see you mention things like "horrible" and "destroying a new machine like this", maybe I'm not understand the full effect of what is going on here, but I see the memory going up when scrolling through data. Maybe the garbage collector did not kick in yet because the OS decided that there is still enough memory?

Is there any other indication than the memory count going up that something is wrong? Do you have any other app that does something comparable which is built by someone else to compare?

Thanks!

[ghost]

Hi @feal87. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[borrmann]

To me it looks like you are not using compiled dataypes. Using x:DataType="YOURDATATYPE" in DataTemplates improves performance significantly as far as I know.

[Larhei]

@jfversluis could you please give some insight when GC on what Os should kick in?
Is there any doc on this. On Android and Windows GC it is working as expected... But on iOS i realy don´t see GC working as expected.

[feal87]

Hi there, thanks for the report!

I see you mention things like "horrible" and "destroying a new machine like this", maybe I'm not understand the full effect of what is going on here, but I see the memory going up when scrolling through data. Maybe the garbage collector did not kick in yet because the OS decided that there is still enough memory?

Is there any other indication than the memory count going up that something is wrong? Do you have any other app that does something comparable which is built by someone else to compare?

Thanks!

Hi, thanks.
The test project definitely allows you to see the problem real time (and you have Vroomer who seems to have the same issue), but here's what I found (all this was tested on a release version of the test application I linked).

It keeps loading the memory pretty costantly and it never clears out while the scrolling becomes very slow (you can see the components building in slow motion).

Memory starts at 157MB and goes up to the above within a minute of scrolling.

I can see the garbage collector is being called multiple times while scrolling from the diagnostic, but it looks like the heap isn't actually increasing in size over time as much as the ram being used by the application.

(first snapshot is after doing one full scroll of the list, the second is after a bunch of scrolls)

I left the application running for 15 minutes afterward, but the memory was never released. Remember all this on a mid-end laptop which shouldn't have any issue in handling a list with 100 items.

Using the Border as first element like @Vroomer suggested does work around the issue even if doing so will inevitably cause a change in the design.

[feal87]

To add more visual to the issue.

Here's a video of the test app with the issue:

2022-12-13.09-05-53.mp4

And here's the video with the workaround suggested by Vroomer.

2022-12-13.09-07-56.mp4

As you can see in the first video (the one with the issue) the scrolling is, let's say it, downright horrible. The second one is more akin to what I'd expect from scrolling such a small list.

Be aware the issue is diminished if you use a very big size of the collectionView control. Make sure to run the application in a relatively small window to show the effects of the issue at best.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[Zhanglirong-Winnie]

Verified this issue with Visual Studio Enterprise 17.7.0 Preview 2.0. Can repro on Windows platform with sample project.
ReproductionTest.AppForMAUI-master.zip

[Chr1970]

I have also a "crash" (probably due to this huge memory consum) in the ReproductionTestApp.
I modified this one with a "ok" button : when you click on this button , I reload the data from the collecvtion view.
About a 5-10 click, a crash appears & an unmanaged exception occurs

à WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|20_0(Int32 hr) à Microsoft.Maui.ViewHandlerExtensions.GetDesiredSizeFromHandler(IViewHandler viewHandler, Double widthConstraint, Double heightConstraint) à Microsoft.Maui.Layouts.LayoutExtensions.ComputeDesiredSize(IView view, Double widthConstraint, Double heightConstraint) à Microsoft.Maui.Controls.VisualElement.MeasureOverride(Double widthConstraint, Double heightConstraint) à Microsoft.Maui.Layouts.GridLayoutManager.GridStructure.FirstMeasurePass() à Microsoft.Maui.Layouts.GridLayoutManager.GridStructure.MeasureCells() à Microsoft.Maui.Layouts.GridLayoutManager.Measure(Double widthConstraint, Double heightConstraint) à Microsoft.Maui.Platform.LayoutPanel.MeasureOverride(Size availableSize) à ABI.Microsoft.UI.Xaml.IFrameworkElementOverrides.Do_Abi_MeasureOverride_0(IntPtr thisPtr, Size availableSize, Size* result) --- Fin de la trace de la pile à partir de l'emplacement précédent --- à WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|20_0(Int32 hr) à Microsoft.Maui.ViewHandlerExtensions.GetDesiredSizeFromHandler(IViewHandler viewHandler, Double widthConstraint, Double heightConstraint) à Microsoft.Maui.Layouts.LayoutExtensions.ComputeDesiredSize(IView view, Double widthConstraint, Double heightConstraint) à Microsoft.Maui.Controls.VisualElement.MeasureOverride(Double widthConstraint, Double heightConstraint) à Microsoft.Maui.Controls.Layout.Measure(Double widthConstraint, Double heightConstraint, MeasureFlags flags) à Microsoft.Maui.Controls.Platform.ItemContentControl.MeasureOverride(Size availableSize) à ABI.Microsoft.UI.Xaml.IFrameworkElementOverrides.Do_Abi_MeasureOverride_0(IntPtr thisPtr, Size availableSize, Size* result) --- Fin de la trace de la pile à partir de l'emplacement précédent --- à WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|20_0(Int32 hr) à ABI.Microsoft.UI.Xaml.IFrameworkElementOverridesMethods.MeasureOverride(IObjectReference _obj, Size availableSize) à ABI.Microsoft.UI.Xaml.IFrameworkElementOverrides.Do_Abi_MeasureOverride_0(IntPtr thisPtr, Size availableSize, Size* result)

CrashReproductionTest.AppForMAUI.zip