[Xamarin.Android] Performance decrease when compared with Xamarin.Forms

[grendello]

I recently tested Xamarin.Android NET6 performance to compare it with "legacy" Xamarin.Android. Two test applications use Xamarin.Forms and MAUI - a very simple layout with just a single Label, no resource dictionary. Unfortunately, MAUI appears to be approximately 100ms slower than Xamarin.Forms. Please take a look at the this gist which contains tables comparing performance of different apps (Xamarin.Forms and MAUI)

I plan to do some profiling of the MAUI app next week to find out where the most time is spent.

[grendello]

MAUI test app used in the tests
MauiPerfTest.net6.zip

[rogihee]

This sounds exactly like the performance hit taken by using Microsfoft.Extensions.DependencyInjection package. The team are considering using an alternative DI container to circumvent this: #880

[AmrAlSayed0]

Is it possible for MAUI to depend only on Microsoft.Extensions.DependencyInjection.Abstractions and provide another package for the concrete implementation of Microsoft.Extensions.DependencyInjection so that other DI packages can just implement the abstraction and configure it to be used with MAUI?

This could be worth the effort if that's actually what's causing the performance issue. Microsoft.Extensions.DependencyInjection runs really quickly on Linux and Windows on .NET Core but it is not as quick on Android and iOS.

[grendello]

I'm not a big fan of DI, especially on mobile, but I realize it's a core design paradigm in XF/MAUI so it's here to stay. However, runtime detection of renderers (and other providers etc) in mobile apps makes for a large time and resource loss, because a mobile app is effectively frozen in time when it's installed. The app won't change unless it's reinstalled (for the most part - unless it downloads some assemblies/native libraries from the internet when it runs, which I hope no apps do) and so everything about it is known statically. Would it be possible to take advantage of .NET6 code generators on the build time to output code that tells MAUI everything it needs to know, so that it doesn't have to dynamically look on startup?

[rogihee]

They have looked into both options (other package and generators), but unfortunately the Microsoft.Extensions.DependencyInjection.Abstractions is not well suited for source generators in its current form. Switching means a breaking change and makes the eco-system weaker bc integrating Blazor will get harder.

For a good discussion and performance metrics see dotnet/runtime#44432.

My gut feeling is that they are trying to squeeze more performance out of the current design. David Fowler was speaking of 10x improvement for reflection, that must have an effect here...

[grendello]

@AmrAlSayed0 quite some time ago I profiled Xamarin.Forms and the bulk of startup time was spent looking for types in assemblies that need to be registered. I haven't been able to profile MAUI yet (since .NET6 doesn't have a managed profiler for mobile that ships with it) but I will hopefully be able to do it soon. Dynamic DI involves a lot of I/O which is generally VERY slow on mobile (especially with the mid to low tier phones, but even high-end devices are blazingly very fast). Comparing Linux/Windows performance to mobile devices, thus, is not a good measure. Keep in mind that mobile devices want to first and foremost preserve the battery, so ideally they spend most time in as low power mode as possible. That means stepping down (and often turning off) CPU cores which are hot-plugged and stepped up only when needed (that's why mobile devices use the BIG.little architecture - they have a number of "slow" but low energy cores and a smaller number of high performance cores). This also includes power delivered to storage, WiFi, RAM, display etc. So when an application suddenly puts a demand for a large amount of I/O, the system needs to wake everything up and face the demand. If the application heavily uses threads and puts a real load on each thread, the system will have to wake up the CPU cores and crank their clocks up to meed the demand. All of this takes time and slows down, especially, application startup.

Imagine a MAUI app that provides a notification service to the user. The app isn't running in the background, in fact, it might not be actually running most of the time - it wakes up only when some notification (or intent, on Android) is delivered and the application has to start in background. The simple MAUI app above takes around 1s to start, one with 5 more controls takes 1.5s. The startup performance is absolutely crucial also because it's the first impression of the end user about the app.

It's crucial for a mobile app to

• start as quickly as possible
• do as little work as possible
• do absolute minimum of necessary work especially on startup
• do not use threads to make things "faster" - use threads to offload long running/blocking operations, but avoid threads on startup as much as possible

[grendello]

@rogihee MAUI is where breaking changes can, and should, happen but before it is released. NET6 is an opportunity to introduce breaking changes (and they are introduced) wherever it makes sense, like here. Also, source generators aren't the only option. It should be possible to introduce a post-build step (in the likeness of the managed linker) that runs over all the gathered assemblies and generates another assembly with the necessary information in as efficient form as possible (i.e. no LINQ, no parsing of strings, no reading of metadata, no reflection, no I/O etc). That single assembly is loaded at startup and its data accessed lazily. The data could be a serialized dictionary (binary serialization, no XML) or a simple array (less efficient, of course), or any other form of a data structure that's efficient to load (preferably in bulk) into memory and accessed quickly in a lazy manner. The generator could analyze the code that takes part in the startup (e.g. the main/launcher activity on Android), look which types are required for startup and prioritize that data (possibly putting it in a smaller, separate, data structure) so that the startup is faster. Even with more complexity involved in MAUI, there's no reason it has to be 5 times slower on startup than "pure" Xamarin.Android (which currently starts in around 300ms for a comparable application with one control and only slightly slower for a more complex app with a few controls)

[rogihee]

@grendello agree 100%, I have been chatting with the team in Discord and making this very point.

[grendello]

I will hopefully be able to profile some MAUI samples soon and then we can see where it gets the hit

[grendello]

Another idea for post-processing, a more complex one, is patching the application code after the build (e.g. with Cecil) so that references to the DI data are injected directly into the code (effectively replacing custom attributes). For instance (and I'm inventing it as I go because I don't know the specifics of MAUI code), whenever a renderer is needed instead of kicking off the DI registration run (e.g. with a call to Registerar.FindType (Some.Type.Here)), the call is replaced with a direct type instantiation.

I remember that Xamarin.Forms code had quite a few instances of dynamic platform checks, too (IsIOS or IsAndroid calls IIRC). These can could be eliminated in a post-processing step too (admittedly, this is trickier than the above FindType suggestion) as they are a waste of CPU cycles in a mobile app - the app, as it is, will not migrate from Android to iOS and vice versa.

[akoeplinger]

I remember that Xamarin.Forms code had quite a few instances of dynamic platform checks, too (IsIOS or IsAndroid calls IIRC). These can could be eliminated in a post-processing step too (admittedly, this is trickier than the above FindType suggestion) as they are a waste of CPU cycles in a mobile app - the app, as it is, will not migrate from Android to iOS and vice versa.

If you use the new .NET5+ OperatingSystem.IsAndroid() and .IsIOS() APIs then these are simple hardcoded bools now (and the managed linker should be able to get rid of unused codepaths)