Steps to Reproduce

1. Run this Xamarin.Mac sample
2. Run this net6.0-macios sample
3. Compare the numbers

Expected Behavior

Same or better performance from CoreCLR (versus Xamarin.Mac legacy running on Mono)

Actual Behavior

Up to 4 times slower running on CoreCLR.

This is likely similar to unoplatform/uno#8890 but the workaround (to disable ObjC exception marshalling) is not possible on CoreCLR.

Environment

• Xamarin.Mac

Xamarin.Mac
Version: 8.11.0.288 (Visual Studio Community)
Hash: 5946727d0
Branch: main
Build date: 2022-05-23 19:40:52-0400

• net6.0

Installed Workload Ids      Installation Source
-----------------------------------------------
wasm-tools                  SDK 6.0.300
macos                       SDK 6.0.300
maui-maccatalyst            SDK 6.0.300
maui-ios                    SDK 6.0.300
maui-android                SDK 6.0.300
ios                         SDK 6.0.300
maccatalyst                 SDK 6.0.300
tvos                        SDK 6.0.300
android                     SDK 6.0.300

Logs

speedscope logs from dotnet trace
DopeTestUno.Mobile_20220526_215531.speedscope.json.zip

Logs shows 99+% time spend in unmanaged code (not surprising if related to #8890). However it also points out some places that are more costly than anticipated.

More details will be added in unoplatform/uno#8890

IsUserType

IsUserType takes 5.2% of the execution time (on the main thread). It is not cached (in flags) and does a few native calls. Also IIRC Selector.GetHandle is not optimized on macOS (at least is was not on mono, never checked with CoreCLR). Fixing this should be beneficial to all platforms/runtime.

Update: fixed with #15149 - it was not really anything specific to CoreCLR, but found in that data