[layout] avoid IView[] creation in LayoutExtensions

[jonathanpeppers]

Context: https://github.com/unoplatform/performance/tree/master/src/dopes/DopeTestMaui

Reviewing dotnet trace output of the "dopes" test sample, 7% of CPU
time is spent in LayoutExtensions.OrderByZIndex():

3.42s (16%)  microsoft.maui!Microsoft.Maui.Handlers.LayoutHandler.Add(Microsoft.Maui.IView)
1.52s (7.3%) microsoft.maui!Microsoft.Maui.Handlers.LayoutExtensions.GetLayoutHandlerIndex(Microsoft.Maui.ILayout,Microsoft.Maui.IVie...
1.50s (7.2%) microsoft.maui!Microsoft.Maui.Handlers.LayoutExtensions.OrderByZIndex(Microsoft.Maui.ILayout)

Reviewing the code in OrderByZIndex():

• Makes a record ViewAndIndex(IView View, int Index)
  for each child
• Makes a ViewAndIndex[] the size of the number of children
• Call Array.Sort()
• Makes a IView[] the size of the number of children
• Iterating twice over the arrays in the process

Then if you look at the GetLayoutHandlerIndex() method, it does all
the same work to create an IView[], get the index, then throws the
array away.

I removed the above code and used a System.Linq OrderBy() with
faster paths for 0 or 1 children. I also made an internal
EnumerateByZIndex() method for use by foreach loops. This avoids
creating arrays in those cases. The ZIndexTests still pass for me,
which proves out OrderBy()'s stable sort:

https://docs.microsoft.com/dotnet/api/system.linq.enumerable.orderby

After this change, the % time spent in these methods went down:

  1.84s (13%)    microsoft.maui!Microsoft.Maui.Handlers.LayoutHandler.Add(Microsoft.Maui.IView)
352.24ms (2.50%) microsoft.maui!Microsoft.Maui.Handlers.LayoutExtensions.GetLayoutHandlerIndex(Microsoft.Maui.ILayout,Microsoft.Maui.IVie...
181.27ms (1.30%) microsoft.maui!Microsoft.Maui.Handlers.LayoutExtensions.<>c.<EnumerateByZIndex>b__0_0(Microsoft.Maui.IView)
  2.78ms (0.02%) microsoft.maui!Microsoft.Maui.Handlers.LayoutExtensions.EnumerateByZIndex(Microsoft.Maui.ILayout)

This kind of goes against the guidance "avoid System.Linq".
But OrderBy() generally seems to be fine?

Results

A Release build on a Pixel 5 device, I was getting:

Before:
103.04 Dopes/s
After:
230.87 Dopes/s

I suspect that was a lot of IView[]'s before!

[jonathanpeppers]

It appears that a regular OrderBy() is the same as this logic. Let me know if I'm missing something, thanks!

[hartez]

Yeah, I only wrote it the hard way because otherwise I'd have to argue with people about the Linq :)

[jonathanpeppers]

I found other places where performance matters, that used OrderBy():

https://github.com/dotnet/msbuild/blob/c2ec5c98a76a5496a36025b3f5e790cca6ea3b2f/src/Build/Evaluation/LazyItemEvaluator.cs#L511-L515

This is used when MSBuild evaluates a project, for every type of item group in a build. It would be called when VS loads a project.

[hartez]

Wondering if we can just drop the OrderByZIndexMethod.

[hartez]

I bet this is a huge chunk of the performance gain.

[rmarinho]

was it returning -1 before ?

[hartez]

Yep.