Made a test app that uses Visual Studio 2017 C# Cross-Platform app / Master-Detail / only UWP as base and modified ItemsViewModel.cs so that it makes 100X items -> 600 items in a list. Then i tried scrolling the list up and down repeatedly with mouse and noticed that Process Memory in Diagnostic tools window easily goes up from initial about 80 MB to for example 500 MB. I tried to use Visual Studio 2019 preview with the same project and Xamarin 4.0 preview and still the same problem happens.
What is causing this? Is there any way to avoid this?
The example is using Listview, can the problem be avoided with different kind of list or is it just general Xamarin problem?
I’m using Windows 10.
The modified code:
var items = await DataStore.GetItemsAsync(true);
foreach (var item in items)
{
for(int i=0; i<100; i++)
{
Items.Add(item);
}
}
View on Developer Community
To find diagnostic information, see the original linked feedback ticket.
I tried to locate this user on GitHub but had no luck. The RecycleElement
caching strategy is was developed to solve this issue. Without it, then each cell is held in memory. That's likely what is going on here. We did Android and iOS and held on UAP waiting for CollectionView
to drop..
Tested with VS 2019 16.1.1. Still does the same leak thing. Took 2 minutes of scrolling to go to 500 MB. The sample project is already using RecycleElement. The word leak is perhaps too weak, maybe megaleak or gigaleak or niagaraleak describes it better?
@samhouts I have done the same test but adding the CollectionView. I used the same template (MaterDetail) loading 600 elements. Then the test consists in scrolling up and down 10 times.
Start the tests with the ListView (RetainElement), first without recycling cells.
With this option, just scrolling during 2-3 minuts can go to 500MB.
Then, tried using RecycleElement:
The memory consumption is lower and release some resources. Although, it does not release everything and it goes up even more slowly.
The latest test is using the CollectionView. Is the best option!.
It releases the resources in an optimal way as you can see in the image.
I hope these tests can help!
This and memory leaks on UWP in general are a real issue for our App & Company. Hope you can solve soon
Any movement on this? We have multiple UWP applications where thousands of items are loaded into a ListView
and CollectionView
. Both exhibit the same or similar behavior of loading all cells into memory. CollectionView
appears to be better from an overall memory utilization standpoint, but overall loading time is abysmal and consistent with ListView
.
Be aware there are also memory leaks in CollectionView
itself:
https://github.com/xamarin/Xamarin.Forms/issues/9288
https://github.com/xamarin/Xamarin.Forms/issues/8928
We have made incremental improvements. Many of these memory leaks are due to problems with individual controls rather than the CollectionView/ListView itself. Please try updating your apps to the latest version. If you are still seeing memory leaks, please let us know what controls are in your templates. Thanks!
@samhouts do you mean the 4.4 or the 4.5 pre-releases?
We are running the latest 4.4 (4.4.0.991640) on a UWP app that loads up a few thousand items into a ListView with custom cells (the cells only contain labels) and are regularly seeing that list take a long time to load (60-90) seconds and it chews up memory. The same UI on Android or iOS loads relatively quickly (5-6 seconds) and memory use is significantly lower.
Would you be willing to update to CollectionView to see if that performs better?
We definitely tried that. It used marginally less memory (around 300MB as opposed to 5-600MB), but the performance was still still on par with ListView. It looked like it was still trying to new up a cell for each item in our list.
@michaelstonis When you say CollectionView is loading all the cells into memory, how are you making that determination? Also, what sort of data source are you using (i.e., is it an ObservableCollection, List
We put some instrumentation on the custom cell that the collection view was using and we saw it get logged for each item in our backing list. This was consistent behavior with what we saw on the ListView control as well.
The list itself that is provided to the ItemsSource property is backed by a ReadOnlyObservableCollection (Reference). This is being populated via a SourceList (DynamicData).
FWIW, this behavior didn't always exist either. UWP at one time was the fastest loading platform. We noticed this first after upgrading from a 3.X version. The behavior seems to be consistent on all of our apps that we have upgraded to 4.X.
This is definitely related to #10473.
i would like to put my findings here. If you are using SwipeView. this is the one causing memory leak for me on Collectionview.
Most helpful comment
@samhouts I have done the same test but adding the CollectionView. I used the same template (MaterDetail) loading 600 elements. Then the test consists in scrolling up and down 10 times.
Start the tests with the ListView (RetainElement), first without recycling cells.
With this option, just scrolling during 2-3 minuts can go to 500MB.
Then, tried using RecycleElement:
The memory consumption is lower and release some resources. Although, it does not release everything and it goes up even more slowly.
The latest test is using the CollectionView. Is the best option!.
It releases the resources in an optimal way as you can see in the image.
I hope these tests can help!