Bug 29712 - listview datatemplate is not correctly reusing cells, and is waisting performance/memory for nothing
Summary: listview datatemplate is not correctly reusing cells, and is waisting perform...
Status: CONFIRMED
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 1.4.1
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Chris King
URL:
Depends on:
Blocks:
 
Reported: 2015-05-04 14:28 UTC by George Cook
Modified: 2017-08-29 12:45 UTC (History)
10 users (show)

Tags: all, functional, virtualization, performance, listview, memory, ac
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 29712 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description George Cook 2015-05-04 14:28:18 UTC
@OtaMares Sure.

Many benefits do come from the image it's true; but my fast cell does other optimizaitons in that it better reuses the native views. I've made a video that demonstrates the difference.

In this video I reduced the image sizes to more normal sizes (640x480) to reduce memory overhead and gc spikes.

I scrolled down 1/4 way in both videos so that the first set of cells had all been created.

The interesting thing is as you get to the bottom of my list of items in my first demo, it begins to get choppy. This is becuase Xamarin creates the content for each damned cell, way over the needs of what's necessary - it's pissing memory and performance away for nothing. In my case it's creating hundreds of content views when it should only create 4. I discard these in the fastcell, which saves some overhead - but it's not avoidable in the current form.

disclaimer: the videos are a bit crap and probably don't show it so much; but I can totally see/feel it when I'm doing it.
video 1 : Xamarin ViewCell. Note how it's choppy all the way through.
https://www.youtube.com/watch?v=9lgvifgjPRw


video 2 : FastCell. Note how it's fast and smooth until I get to the point in the list (really far down) where the datatemplate starts being a total dick (@ 30 seconds into video)

https://www.youtube.com/watch?v=lxOpBO2X42A

I realized that at the end of video 1 I did a pull to refresh which made the list grind to a halt - that's because Xamarin reloads the list and then creates all the content in the datatemplate again. I would so love to fix this..

I'll raise a bug about this as it's a poor show on their behalf. Lists are of huge importance in mobile and to have such a wasteful implementaiton of DataTemplate and ViewCell simply beggars logic.

I used very heavy xaml to show off the point. The fast cell only does layout once so wont' update for orientation changes; but that's easily fixed. it also has some hacks to get it to layout it's subviews. 

This is as far as I can get with optimizations while Xamarin block us with the crappy DataTemplate implementation. Why the hell it calls create content is totally beyond me.


@TheRealJasonSmith is this on your radar? it seems like an easy win to me.. can we not fix the Datetemplate and VIewcell to not produce so many contents when the os has flyweights (like iOS - I presume android and windows have something similar too), or better still let subclass it and override the relevant expensive methods so we can make our own optimizations. There is no reason for anyone to have to drop down to native, even when using Xaml if you guys fix that.


Here's the xaml the only difference between the 2 videos is that I change ViewCell to local:FastCell, and change the label text.




				<?xml version="1.0" encoding="UTF-8"?>
		<ViewCell xmlns="http://xamarin.com/schemas/2014/forms" 
		xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" 
		x:Class="TwinEvents.Core.Media.View.MediaCellXaml"
		xmlns:local="clr-namespace:TwinEvents.Core.Media.View;assembly=TwinEvents"
		>
			<AbsoluteLayout BackgroundColor="Black">
				<local:FastImage x:Name="ImageView" AbsoluteLayout.LayoutFlags="WidthProportional" AbsoluteLayout.LayoutBounds="0,0,1,260"/>
				<local:FastImage x:Name="UserThumbnailView" AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="5,240,40,40"/>
				<Label x:Name="NameLabel" Text="XAM VIEW CELL" TextColor="White"  AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="50,250,100,20"/>
				<Label x:Name="DescriptionLabel" Text="XAM VIEW CELL" TextColor="White" AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="50,270,100,40"/>
				<StackLayout Orientation="Horizontal">
					<StackLayout AbsoluteLayout.LayoutFlags="WidthProportional" AbsoluteLayout.LayoutBounds="0,0,0.3,310">
						<Label Text="XAM VIEW CELL" TextColor="White"  />
						<Label Text="XAM VIEW CELL" TextColor="White" />
						<Button Text="touch me" />
						<Entry Text="changeme" />
					</StackLayout>
					<StackLayout AbsoluteLayout.LayoutFlags="WidthProportional" AbsoluteLayout.LayoutBounds="0.3,0,0.3,310">
						<Label Text="XAM VIEW CELL" TextColor="White"  />
						<Label Text="XAM VIEW CELL" TextColor="White" />
						<Button Text="touch me" />
						<Entry Text="changeme" />
						<local:FastImage x:Name="UserThumbnailView2" AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="5,40,40,40" WidthRequest="40" HeightRequest="40"/>
						<local:FastImage x:Name="UserThumbnailView3" AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="5,80,40,40" WidthRequest="40" HeightRequest="40"/>
						<local:FastImage x:Name="UserThumbnailView4" AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="5,120,40,40" WidthRequest="40" HeightRequest="40"/>
					</StackLayout>
								<StackLayout AbsoluteLayout.LayoutFlags="WidthProportional" AbsoluteLayout.LayoutBounds="0.6,0,0.3,310">
						<Label Text="XAM VIEW CELL" TextColor="White"  />
						<Label Text="XAM VIEW CELL" TextColor="White" />
						<Button Text="touch me" />
						<Entry Text="changeme" />
						<local:FastImage x:Name="UserThumbnailView5" AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="5,40,40,40" WidthRequest="40" HeightRequest="40"/>
						<local:FastImage x:Name="UserThumbnailView6" AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="5,80,40,40" WidthRequest="40" HeightRequest="40"/>
						<local:FastImage x:Name="UserThumbnailView7" AbsoluteLayout.LayoutFlags="None" AbsoluteLayout.LayoutBounds="5,120,40,40" WidthRequest="40" HeightRequest="40"/>
					</StackLayout>
		
						</StackLayout>
		
			</AbsoluteLayout>
		</ViewCell>
Comment 1 George Cook 2015-05-04 15:14:33 UTC
sorry forgot to put links to the gist:
https://gist.github.com/georgejecook/2e69d336350528494b00
Comment 2 George Cook 2015-05-04 20:54:51 UTC
I've gone through this a lot more, and I can see the problem very clearly in the profiler.
Only 3 cells are created by UITableViewColletion; but Xamarin creates a cell for every single item in the datasource.

This is incorrect. why are the template items simply reusing the the xamarin cell which is connected to the view collection view cell?

Once I have scrolled down to the bottom of my list of hundreds of items scrolling is so smooth that I would defy anyone to tell me it wasn't nativ;e yet it's all the xaml you see above!

however, when I scroll down the first time it is slow and jitters. This is all because it is creating hundreds of items, which I don't even use, and xamarin shouldn't use either. 

I've been doing iOS dev for a very long time, and I'm happy to give more notes about this if you guys need - but I suspect this is an issue for android too.

please please please fix this. I love xamarin forms, and think it's awesome. a lot of smack talk get's done by people who can't write custom renderers and let's face it, if we can show colleagues/clients super smooth scrolling, while using complicated xaml cells like the one above.. well there'd be no more caveats in your documentation about performance and it would be extremely amazing stuff.

if you can't do it for me, then do it for the community!! :)
Comment 3 tim.ahrentlov 2015-05-06 03:27:23 UTC
On a more paranoid note, I am thinking, this could be the sort of thing that Apple comes down on. To systematically create apps that deliberately degrades performance, would not be something that they would want to endorse. Don't awaken the giant.
Comment 4 George Cook 2015-05-14 19:45:20 UTC
@chris, my most up to date sample is here : https://github.com/georgejecook/TwinTechsXamarinLib, which will also be of interest to you for https://bugzilla.xamarin.com/show_bug.cgi?id=29820
Comment 5 George Cook 2015-05-14 19:47:01 UTC
sorry. here : https://github.com/twintechs/TwinTechsFormsLib
Comment 6 Chris King 2015-05-21 18:21:35 UTC
George, thanks for your reporting, investigation and offer to help. I'll take you up on that when I'm tasked with fixing this bug. At the moment we're doing a big bug triage fix (which could take a while) but once that's done I  hope to get a mandate to work on visualization in general and when that happens I'll update the this bug.

Warm regards,
Xamarin Forms Team
Comment 7 George Cook 2015-05-21 19:09:31 UTC
@chris no worries. in the meantime, could we possibly get some love on 29820 as that would allow myself and others to get the huge performance gains I've shared. Even if it was only exposed at the renderer level, so we could subclass the listview renderers, and feed in our heights like that.

Good luck with your bugs :)
Comment 8 david 2015-06-02 10:07:47 UTC
I'd like to see the ListView renderer's DataSource property be made public, or at least protected, instead of internal.