Android perfomance improvement

[anpin]

Is your feature request related to a problem? Please describe. Avalonia is very slow on Android with a single page with 64 x 64 matrix of buttons nested in ScrollViewer and ItemsRepeater

Describe the solution you'd like Make it fast and great as the desktop version!

Describe alternatives you've considered Reorganizing layout might be a choice, but this kind of layout is often needed to present actionable data at the same time

Additional context Repro is here

[robloo]

This might be an Android-specific issue. I also have seen poor performance with Xamarin and Uno Platform on Android as well. It's a difficult platform it seems. However, it's generally best practice to always use AOT native compilation for mobile. Are you able to test this on your end?

Another reason I say this seems to be Android-specific is look what the iPad can do (and assuming iPhone has similar performance). https://github.com/AvaloniaUI/Avalonia/pull/7565#issuecomment-1049496241

Bottom-line, I'm not sure any XAML framework has solved Android performance yet... unfortunately.

[anpin]

I actually have made similar (with more features) layout on Xamarin.Forms and it worked quite well on Android. It had a bit of lag from time to time, but was totally usable. Will try AOT later.  On Wed, Apr 6, 2022 at 5:32 PM, robloo @.***> wrote:
This might be an Android-specific issue. I also have seen poor performance with Xamarin and Uno Platform on Android as well. It's a difficult platform it seems. However, it's generally best practice to always use AOT native compilation for mobile. Are you able to test this on your end? Another reason I say this seems to be Android-specific is look what the iPad can do (and assuming iPhone has similar performance). #7565 (comment) Bottom-line, I'm not sure any XAML framework has solved Android performance yet... unfortunately.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[robloo]

Yea, Xamarin.Forms performance will always be a bit better since it is simply mapping to native controls instead of running a full UI framework (not to mentioned Microsoft owns Xamarin itself so can optimize where Avalonia can't). That said, I know years ago Android performance was always worse than iOS performance because of the way interop had to work with Java runtime. It was very inefficient compared to what was possible with iOS. So a lot of my thoughts are probably based on old information that is largely mitigated now with AOT on Android as well. I'm sure a lot of progress has been made other places as well.

That said, I've definitely noticed a performance difference between Android/iOS in both Uno Platform and now Avalonia as well. So there might still be inefficiencies in the way the two platforms work with Xamarin (now Maui).

[ili]

@robloo sorry, but you are incorrect. First of all your words looks like "this is not an Avalonia's problem, this is just because Android is slow, just use iOS" (i do believe you don't want to say smth. like this, but it sounds so...)

Android by itself has no problems with Skia (Chrome & Flutter apps works good even on old lo-end devices). Also you can check noesis sample - excellent performance everywhere (noesis has it's own 2d vector engine). Even on desktop (russian) - there are problems (yes tests are synthetic but the problem is here)!

And yes you are right - .Net has poor startup time on Android, this is .Net problem, but it has no runtime problems by itself.

As for me - i can't use Avalonia because of poor performance on lo-end devices (enterprise b2b devices like POS stations, Handhelds and so on are mostly lo-end). So guys like me with blooding heart once again should use painful Xamarin.Forms / MAUI (to be honest can't say for now that MAUI is pain but i do expect it to be Xamarin.Forms with better build tools).

So Avalonia do have performance problems! And Avalonia team should recognize the problem and solve it.

@danwalmsley

[maxkatz6]

@ili Both statements are correct.

• Avalonia has some perf problems, especially on low end devices. For instance, styling initialization takes 60% of startup time by itself (control themes PR will improve it, but that yet to be tested). Using our own Skia wrapper should also marginally improve overall perf, composition renderer already has better memory usage (==less allocations and gc time).
• And .NET on Android has worse performance comparing to iOS, what always was well known fact.

As for now, Avalonia can only continue to do micro-optimizations for all platforms. And it's not really clear what can be done for Android specifically. If there are Xamarin/Android developers, who are experienced in this kind of tasks, help will be appreciated.

[robloo]

@ili It sounds like we are saying very similar things. I wouldn't say what I said was incorrect.

I also know the issue is with .net on Android and is not an Avalonia specific issue. Keep in mind my comments were general to .net. I wasn't saying anything about Android or iOS being better or anything to due with skia. I am simply stating .net performance on Android is inferior to iOS and this is a known issue for a while. I also added I've seen this with XF and Uno Platform already.

[anpin]

MAUI team seems to make performance tests against Avalonia and other frameworks https://github.com/jsuarezruiz/cross-platform-performance

[emmauss]

MAUI team seems to make performance tests against Avalonia and other frameworks https://github.com/jsuarezruiz/cross-platform-performance

All 3 tests does not have times for Avalonia.

[anpin]

@emmauss I have seen that, but since that repo was published just yesterday I suppose they are planning to do add this shortly

[robloo]

Nice find! The fact that Avalonia and Uno are already rows in the tables is very promising.

[robloo]

jsuarezruiz Repository was just taken offline or made private... Hopefully it wasn't done for commercial reasons but that would be typical Microsoft.

[ili]

@maxkatz6

• Avalonia has some perf problems, especially on low end devices. For instance, styling initialization takes 60% of startup time by itself (control themes PR will improve it, but that yet to be tested). Using our own Skia wrapper should also marginally improve overall perf, composition renderer already has better memory usage (==less allocations and gc time).
• And .NET on Android has worse performance comparing to iOS, what always was well known fact.

OK, both of them are in master.... But, composition renderer is not available for Android (easy to fix)

I'v builded control catalog demo with composition apk - release build from here

Can't see any difference with old apk without composition and control themes :(

Just try to open Calendar - 10 seconds - first time, 5 - on second one :((

PS. also there are the bug in new build - after minimizing & restoring (or block/unblock the phone) i do see black screen PPS FYI MAUI - is pain! :)))))))

[robloo]

10 seconds to load a calendar!? That's much worse than expected. Uno has significantly better performance in that control and the underlying UI elements are native Android control primitives (so there is more interop). If Avalonia is rendering everything it should have less interop and be even faster... this is strange.

[ili]

@robloo in general there are 7 calendar controls on the page )) On CalendarDatePicker page it takes1.5-2 seconds to expand calendar.

There are problems with "many" components on a screen... and it is hard to how much is this "many"

[ili]

@maxkatz6 @robloo

DISCLIMER - Avalonia is great! And Avalonia's team is great too, and has done awesome job for the past year, for ex a year ago it was not even possible to run Control catalog on this device.

Control catalog video builded from the latest master with composition enabled on real world device :) (10 seconds was for my phone, be patient!)

[Sorien]

@ili maybe you could try to build with https://github.com/AvaloniaUI/Avalonia/pull/8422 ?

[ili]

@Sorien i'll try to do it next week, but usually lazy load improves startup time, here it looks like smth else causes the problem

[robloo]

@maxkatz6 For the Calendar specifically, UWP version probably had lots of architecture changes and optimizations compared to WPF. That might be part of the problem here.

The Uno team got the WinUI 3 source code to port. Can the Avalonia Team ask for the WinUI3 source code for a new port as well?

I would be willing to help with the port itself.

[timunie]

I wonder if the amount of DayButtons are the bottle-neck and if so, I wonder if we can have a more lightweight control in there.

[ili]

@maxkatz6 For the Calendar specifically, UWP version probably had lots of architecture changes and optimizations compared to WPF. That might be part of the problem here.

@robloo please just watch the video https://youtu.be/QlQ1Lbjyyqo calendar is just the sample, problem is somewhere in layout calculating

[robloo]

Calendar is an example for this issue. It definitely needs a re-write and we should be able to get a much newer version of the code. I know the UWP architecture of this control will perform better. Similar optimization can likely be done for other controls one-by-one as well. But that's a slow process and likely not possible with breaking changes after 11.0.

I guess i was thinking with native .net compilation and Avalonia rendering itself entirely with skia in a surface (no interop with Android native controls) there should be something close to Flutter performance. These load times are very far away from that though... something must be fundamentally wrong in .net Android honestly. Even an unoptimized Avalonia should be better than this. I don't know how we ever expect to close the performance gap starting here.

Note that Uno has similar issues as well and it is following UWP -- which was designed for decent performance on mobile processors from years ago. So I'll say it again, something is fundamentally wrong with .net Android in design or implementation.

[Gillibald]

@ili What ABI are you using for your release build? It is possible that you are using the wrong one for your device and that's why you are getting a poor performance.

[ili]

@Gillibald i can't even see how the application with incorrect ABI would start (may be it is about my Android miss knowlege). I do make the build from this sources without any changes :) (all I'v changed in the brunch - enabling composition renderer for Android).

RLY i'm far away from professional Android developer, so if you do have some experiments i can make i'll try them )

[ili]

@robloo particular calendar's optimization would not solve the issue. Even sample app with 64 buttons, it is not a fantastic to have 64 buttons on the screen (there are 17" Android POS stations). And once again - it is not Android issue, just compare Test1.Avalonia and Test1.Wpf from here - and yes, sample is syntetic, but WPF runs without any problems, while Avalonia - does (try to scroll or resize the window, OK, yes WPF resizing is not so smooth as wanted but much better then Avalonia's results).

It really looks like smth in layout calculation (may be if you would run samples on Windows ARM machine you would see the same problems... may be)

UPD: interesing point - compare Test1.Avalonia & Test3.Avalonia from here - Test3 uses TextBox with loooooong text, and it really shows different behaviour

[ili]

Looking at enabled debug output, after the sturtup (I'v added log time), all logs are got from the emulator:

// this occures after i click Calendar button, i gues this is to redraw button

[0:] 18:58:16.625 [Layout]Started layout pass. To measure: '1' To arrange: '1'(LayoutManager #1486987678) 
[0:] 18:58:16.63 [Layout]Layout pass finished in '00:00:00.0020747'(LayoutManager #1486987678)  

// fast

// the next is page layout calculation

[0:] 18:58:16.705 [Layout]Started layout pass. To measure: '6' To arrange: '6'(LayoutManager #1486987678) 
[.ControlCatalo] Explicit concurrent copying GC freed 6317(268KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 2176KB/4352KB, paused 202us total 2.926ms
[.ControlCatalo] Explicit concurrent copying GC freed 611(68KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 2139KB/4279KB, paused 201us total 2.900ms
[0:] 18:58:27.226 [Layout]Layout pass finished in '00:00:10.5186217'(LayoutManager #1486987678) 

// here calculation finished - 10 seconds, after this event surface is drawn (!) i can't see the lag between this evelt and redraw

[.ControlCatalo] Explicit concurrent copying GC freed 78(18KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 2137KB/4274KB, paused 202us total 3.520ms

Next we would change selected page and then click Calendar again:

// button click

[0:] 19:08:45.439 [Layout]Started layout pass. To measure: '1' To arrange: '1'(LayoutManager #1486987678)
[0:] 19:08:45.443 [Layout]Layout pass finished in '00:00:00.0021005'(LayoutManager #1486987678)

// finished, 
// next

[.ControlCatalo] Explicit concurrent copying GC freed 1673(95KB) AllocSpace objects, 0(0B) LOS objects, 49% free, 2137KB/4274KB, paused 205us total 2.563ms
[0:] 19:08:48.647 [Layout]Started layout pass. To measure: '6' To arrange: '6'(LayoutManager #1486987678)
[0:] 19:08:51.762 [Layout]Layout pass finished in '00:00:03.1131976'(LayoutManager #1486987678)

// and here is surface redrawn!

The pointa are: on second activation we do see that layout calculation takes 3 seconds (not so aweful as 10 on the first activation, but it looks like long...)

but! see the lag between click calculation finished and page calculation started - this is 3 seconds! visually i see 5-6 seconds between click and page redraw... it looks like GC takes this time (that's why i added log time to output, to see lag between calls)

and this situation is stable on switching from the Calendar page and back....

I can suggest next points here:

1. layout calculation takes long time
2. layout calculation causes memory preassure
3. there are no rendering problem - rendering is fast (here i do suggest that no rendering occures while layout is calculated... ) - looking the emulator and log output on the same screen page is redrawn milliseconds after the layout calculation is finished

[Gillibald]

You can use dotnet trace to get actual profiling. We might be able to find the hot paths that are causing the performance hit.

https://docs.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dsrouter

[timunie]

Yes, looooong Text is known to be slow. If you need really long Text, use AvaloniaEdit. It has virtualization and is therefore much faster.

[maxkatz6]

just compare Test1.Avalonia and Test1.Wpf from here - and yes, sample is syntetic, but WPF runs without any problems

That's went offtopic, but I was looking into LX before. It is pretty a bad example here, as it puts tons of controls inside of the stack panel without any virtualization. While WPF works slightly better there, it's still way not optimal solution for both frameworks as most of retained GUI framework. Long test processing is slow in Avalonia too, as we don't have textbox virtualization. AvaloniaEdit solves this problem usually as @timunie mentioned.

Saying that, I would repeat my point from previous comment, and let's stay on topic. If you are interested, you can try to build avalonia WASM with FullAOT and deploy somewhere or locally, and open this web site on the android phone. Resulting code generation might show interesting results.

@grokys is there known perf issues with layouting in Avalonia? Probably something GC intensive.

[ili]

@maxkatz6 my point is - Avalonia do have perfomance problem on layout calculating, Android devices are just mostly suffering here. That's why i do show some WPF comparations.

[grokys]

is there known perf issues with layouting in Avalonia? Probably something GC intensive.

It's quite a few years since I benchmarked why Calendar is so slow, but iirc the problem wasn't our layout code as such, it was just that there are a lot of controls which cause a lot of property reads and text measurement.

Since I last benchmarked it, we've improved performance there a lot, so it could be that now something else will show up in profiling. If it's still a large number of property reads that are causing problems then #8600 may help.

However this this may give us a clue as to why Android performance here is so bad: #8690. That will be called on every property read.