[net6] xamarin_get_frame_length performance regression

[jeromelaban]

Description

When invoking a UIView property (and likely anything else), there's a new native method being invoked xamarin_get_frame_length which incurs a very high cost when invoking methods.

This causes a very large performance regression (25:1 in some of our test cases) when comparing with legacy Xamarin.

The instruments traces below are from a physical device running arm64.

Steps to Reproduce

Create an application which invokes UIView.get_SuperView, invoke it in a loop.

Expected Behavior

Here's the Legacy Xamarin result:

Actual Behavior

Here's the .NET 6.0 RC1 result:

Environment

.NET 6 RC1 (https://aka.ms/dotnet/maui/rc.1.json)

Build Logs

Available on demand.

Example Project (If Possible)

None, see repro steps above.

[jeromelaban]

The issue's description is now up to date.

[spouliot]

It might be the project options (or a different default value in dotnet vs legacy) but xamarin_dyn_objc_msgSend* APIs (that calls xamarin_get_frame_length) are used when ObjC exceptions are marshalled. If that's disabled then that (known to be slow) code should not be reached.

[rolfbjarne]

It might be the project options (or a different default value in dotnet vs legacy) but xamarin_dyn_objc_msgSend* APIs (that calls xamarin_get_frame_length) are used when ObjC exceptions are marshalled. If that's disabled then that (known to be slow) code should not be reached.

That's correct, we've changed the default so that exception marshalling is now on by default.

Adding this to the csproj should get the old behavior back:

<MtouchExtraArgs>--marshal-objectivec-exceptions:disable</MtouchExtraArgs>

[jeromelaban]

Thanks @rolfbjarne, @spouliot! Would you have some documentation about this change (or the feature itself) aside from #4940 and why you chose to use this mode? It's drastically changing the performance characteristics, but I wonder about the use cases, particularly if it can be enabled per method. Thanks!

[rolfbjarne]

@jeromelaban exception marshaling is documented here: https://docs.microsoft.com/en-us/xamarin/ios/platform/exception-marshaling

Making it enabled by default is something we plan on putting in the release notes (it's listed here: #10574)

That said, it should be easy enough to fix that enhancement, since we'd only have to add a way to override the default logic.

[jeromelaban]

Thanks for the details! We'll likely use the original behavior for now even if the exception marshalling is incorrect. It's been working this way for many years and we've coped with it all this time, so we can continue doing so for a while :)

[rolfbjarne]

I've fixed #14961, so it will be possible at some point to improve speed at the cost of app size (not for the first stable release, but for the next Xcode release we'll support, that be either Xcode 13.4 or Xcode 14.0).

We might still want to look into if there are other performance improvements that can be done, so I'm keeping this open for now, but postponing until .NET 7.

[rolfbjarne]

I just did a very simple perf test on Mac Catalyst / ARM64:

var watch = Stopwatch.StartNew ();
for (var i = 0; i < counter; i++) {
	var x = view.Superview;
}
watch.Stop ();

The results are for 20.000.000 iterations:

Mode	Time
Default release build	31.69s
Release build with exception marshalling disabled	2.55s
Release build with P/Invoke wrappers	2.45s

So I think the P/Invoke wrappers is the way to go here, without having to disable exception marshalling (it's even faster!):

<PropertyGroup>
    <MtouchExtraArgs>--require-pinvoke-wrappers:true</MtouchExtraArgs>
</PropertyGroup>