-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Horrible performance/memory usage with CollectionView depending on size on screen #12013
Comments
Wrap the DataTemplate of CollectionView in Border. There is a bug that prevents proper view recycling otherwise: #10560 |
Isn't grid's row and column index starting with 0?
|
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... |
Ah, ic. |
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 @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. |
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. |
@jfversluis could you please give some insight when GC on what Os should kick in? |
Hi, thanks. 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).
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. |
To add more visual to the issue. Here's a video of the test app with the issue: 2022-12-13.09-05-53.mp4And here's the video with the workaround suggested by Vroomer. 2022-12-13.09-07-56.mp4As 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. |
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. |
Verified this issue with Visual Studio Enterprise 17.7.0 Preview 2.0. Can repro on Windows platform with sample project. |
I have also a "crash" (probably due to this huge memory consum) in the ReproductionTestApp.
|
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
The text was updated successfully, but these errors were encountered: