Generic UserControl Performance (Android)

[robloo]

I have some views implemented with generics. These views have very poor performance, easily up to 10 seconds in some cases. Heavy, heavy optimization has been done to bring performance improvements and it's now down under ~2 seconds using a lot of x:Load, XAML simplification and smarter/special-purpose code-behind. However, with the level of optimization done here I would expect these views to be almost instantly loaded, they are not. I'm almost out of ideas to optimize further.

My thinking now is this is due to the use of generics. Other views, of a higher complexity, don't seem to have these delays (this is subjective right now though so I could be wrong).

My questions are:

1. Could the following use of generics be the cause of very poor performance? If so, are there any suggested work-arounds?
2. Is the depth of inheritance for user controls like this potentially a performance bottleneck as well?

EditorBase (non-generic base) -> HierarchicalEditor (generic base) -> ItemEditor -> Editor.xaml.cs + Editor.xaml

public partial class EditorBase : UserControl

public partial class HierarchicalEditor<T> : EditorBase
    where T : class, new()

public partial class ItemEditor: HierarchicalEditor<actual_type> { }

public sealed partial class Editor : ItemEditor

Note that this design is required in UWP because x:TypeArguments isn't supported microsoft/microsoft-ui-xaml#931

[jeromelaban]

Generics are generally forcing the JIT to run. Are you running with AOT?

[jeromelaban]

It's always been like this, AOT is disabled visually but runs properly with the CLI, same goes with profiled AOT "Startup tracing".

In all cases, we (uno) can't do anything about generics performance, this is coming from the runtime. With AOT, generics are optimized to a certain degree, but fails to do so if there are static member or others (rules change over time).

I'd suggest not using generics and use T4 templates, roslyn generators or just plain type composition to avoid this.

[robloo]

I know there is nothing you can do about generics performance overall with Mono. I guess I was wondering if you could confirm from your experience if this code is likely to cause a performance issue. This is a standard work-around for the loss of x:TypeArguments from WPF so you might have seen it before.

If do think this is generics I can look at alternatives. There are no good ones from what I see though. Code generation is the only somewhat tolerable solution in my case but it really hurts maintainability and code simplicity. There are over half-dozen editors using this technique and dropping generics to create a control for each type is not feasible long-term.

[jeromelaban]

It can cause performance issues in extreme generics uses but in all cases, without AOT, Xamarin.Android is extremely slow so I would not bother making performance assumptions based on the JIT.

[robloo]

Ok, I'll certainly attempt to enable AOT and run with that. I really didn't know that was possible without VS Enterprise. That will be a huge help for sure, thanks!

If you don't hear back from me on this assume it was fixed with AOT. Otherwise, if that's not it, I have one other idea related to setting a ListView ItemTemplate using XamlReader.Load() at runtime. Not sure if that would be a performance hit and haven't tested alternatives.

[robloo]

I setup build scripts to create the app outside VS and include AOT. AOT doesn't really affect the performance in this area -- as expected with generics as you mentioned. Initial load of the views in question still takes ~2 seconds in the worse case. Loading the views a second time is nearly instant. This is good enough I suppose for initial release. I might revisit this in the future with code generation and see if it significantly improves things. (Mono could be a lot smarter about it though and basically generate equivalent code ahead of time for the types detected with static analysis).

Overall app responsiveness is definitely improved with AOT so I'm grateful for your tip. I'm going to just mark this as an answer to close it.