Skip initial assignments in property mapper (take 4)

[MartyIX]

Credits to @albyrock87 for helping me refactor the PR to be acceptable for .NET 9!

Description of Change

This is very much work in progress but it seems to show promising performance implications¹.

Introduction to the problem

To understand this PR, it is good to know that each virtual view (e.g., MAUI's <Entry>) is mapped to a platform view (e.g., <TextBox> on Windows) on each supported platform².

Now when a XAML page with a single <Entry Text="Hi" /> element is to be to displayed to user by MAUI, MAUI creates a new platform view (i.e. TextBox on Windows; see doc).

In a next step, MAUI must make sure that all properties of <Entry> are set (mirrored?) to the new TextBox instance. So MAUI maps all properties of the virtual view (<Entry>) to corresponding properties of TextBox. So in simple words, what happens when MAUI initializes a platform view is the following (pseudocode):

TextBox platformView = new();

// Map things like: Width, Height, Opacity, IsVisible, Padding, Margin and many others.
foreach (string propertyName in virtualView.Properties) {
   MapProperty(propertyName, virtualView, platformView);
}

(Code Listing 1)

It's technically more complicated but this is the gist. Now what #17303 observes is that the mapping is not always perfect. One can see it here:

maui/src/Core/src/Handlers/View/ViewHandler.Windows.cs

Lines 42 to 90 in 7a6b1af

	public static void MapTranslationX(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapTranslationY(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapScale(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapScaleX(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapScaleY(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapRotation(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapRotationX(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapRotationY(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapAnchorX(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}
	public static void MapAnchorY(IViewHandler handler, IView view)
	{
	handler.ToPlatform().UpdateTransformation(view);
	}

So suppose that a new <Entry> is to be added to screen by MAUI on Windows, then MAUI calls on a new TextBox mapping methods MapTranslationX, MapTranslationY, MapScale, etc. which all do the same work. So it's clear it can be called just once to achieve the same.

One might think that it's not a big deal to set, e.g., platformView.Projection = null (like here)³. And that's actually a big deal because each such call is an interop call. Interop calls much more costly than simple .NET calls⁴. In a sense, it's a death by tousand cuts because as a MAUI app gets more complex, everything takes longer and longer to display. So each removed interop call counts because it expands how big MAUI app one can implement⁵

How to MAUI improve performance?

To improve MAUI performance, one needs to decrease the number of interop calls needed to display a single MAUI window, that is something like:

#virtualViews * #properties ~= virtualViews * 50

Previously tried approaches

• One approach is to "batch mapping calls" (simply skip some mapper method calls because each such call does the same work as illustrated above. This was done in [Windows] Add WindowsBatchPropertyMapper to save unnecessary work when initializing views #24417 but it was rejected.
• Another approach is [Windows] Skip initial assignments in property mapper (take 3) #23987 which stores a variable isPlatformViewBeingInitialized and use it in mapper methods to avoid doing work that is not necessary. For example, it's not necessary to set platformView.Opacity = 1 after the platform view is instantiated because that's its default value.
  • A disadvantage of this approach is that the optimizations are somewhat scattered throughout the codebase. Moreover, the work is done for each platform separately.
  • @albyrock87 implemented much more polished version of this approach here main...albyrock87:maui:handler-init-flag.

This PR

• This PR is similar to the previous approach ([Windows] Skip initial assignments in property mapper (take 3) #23987) but the idea is to decide if a mapper is to be called in PlatformMapper itself and not in platform methods as the previous approach. So we decide "sooner" and this approach is more "centralistic". It IMO follows this comment by @PureWeen.
  • An advantage is that one can define that, e.g., opacity = 1 is default value and if a platform view is instantiated, then when property mapper is called for the first time for that platform view, we don't need to assign opacity = 1 and many others because arguably almost all properties are set to default values and just a few are set to "useful values" (e.g. Entry.Text = "Hi" but margin = 0, padding = 0, opacity =1, etc. etc.).
  • An issue is that this PR is implemented with a modification of public API so, if accepted, it would target only .NET 10 which is not great. But perhaps one can somehow avoid modifying public API.
  • Arguably this approach has bigger impact than previous approaches, so I tend to think it's reasonable.

Performance impact

(Compare Handler.MapHeight in both images, etc.)

Main	PR

Speedscopes:

• Main: 1736595664.main.speedscope.json
• PR: 1736595246.init-xplat.speedscope.json

Search for Handler.Map

Issues Fixed

Fixes #17303

Footnotes

1. As expected. ↩

2. Read Windows, Mac Catalyst, Android, iOS, etc. ↩

3. Interestingly, setting some platform view properties (like RenderTransform in WinUI) can be much more costly than others. It seems that some parts of WinUI are much less optimized than others. ↩

4. MAUI on Windows is based on WinUI framework and WinRT is used for interop calls (see how costly is accessing Panel.Children here). On Android, one needs to do interop calls as Android apps runs on java virtual machines (JVMs). ↩

5. I'm not talking about something takes a microsecond, I'm talking about a grid that one can display in 1 second or in 100 ms (see (see https://github.com/dotnet/maui/issues/21787#issuecomment-2453520427 to get some sense what I'm talking about). So this issue is about a real-world issue where even mid-size apps can suffer from poor performance. ↩

[bcaceiro]

Amazing work @MartyIX . This should be a top priority for the team to review + come up with a feasible solution targeting .net9. One of the major issues that everyone is always talking about is performance. CV, loading pages, etc.

This seems very promising to instantly improve performance without changes in a codebase ( again from a user/customer pov)

Also : it would be helpful I guess to have a generic method to count the interop calls and see the impact ( not sure if already exists)

[MartyIX]

Also : it would be helpful I guess to have a generic method to count the interop calls and see the impact ( not sure if already exists)

I added a simple comparison to the OP. It shows that by removing setting padding one saved about 180 ms in total when I displayed my grid 10 times. So that property alone seems to shave off 18 ms (more or less) for each display of my grid. This PR is really suboptimal but I think it saves ~50 ms to display each grid. For me

• 50 ms is better than nothing
• 100 ms okay-ish
• 200 ms jackpot (because we would get to the perf of WinUI itself)

We will see what we can get. Again, this is not finished.

To answer your question, I'm not aware of a way to count interop calls precisely but https://www.speedscope.app/ gives good enough estimation of improvements so I'm currently happy with it.

[marcojak]

Interesting one and definitely something for the team to investigate further for its potential.
Good work.

[MartyIX]

Intentionally for now to avoid commiting too many changes.

There are public API changes in this PR!