[android] .NET 8 performance regression in System.Reflection.MethodInfo/ConstructorInfo.Invoke()

[jonathanpeppers]

Description

.NET 7 added a code path that uses System.Reflection.Emit for ConstructorInfo/MethodInfo for coreclr. This makes sense for throughput, scenarios like ASP.NET.

On mobile, however, we are more concerned about a fast startup. I found that we may have accidentally introduced this behavior for Mono (or at least Android) in .NET 8:

#72717

In .NET MAUI apps that heavily use things like data-binding, Microsoft.Extensions.DI, etc. It appears that this change noticeably slows down startup.

In my benchmark, I setup a "first run" / "cold start" scenario:

Version	Method	Mean	Allocated
.NET 7	ContructorInfo_Invoke	530.5 us	552 B
.NET 7	MethodInfo_Invoke	457.6 us	128 B
.NET 8	ContructorInfo_Invoke	607.7 us	4.09 KB
.NET 8	MethodInfo_Invoke	1,202.1 us	2.38 KB

/cc @steveisok

Reproduction Steps

Try my instructions here: https://github.com/jonathanpeppers/BenchmarkDotNet-Android/tree/System.Reflection

Expected behavior

We probably shouldn't hit the S.R.E codepath by default on Android.

We should have a flag to opt into it? It may be useful for some apps, although it appears to slow down startup in the apps I've tried.

Actual behavior

We hit the S.R.E codepath by default on Android.

Regression?

Yes, it appears .NET 7 does not have this issue.

Known Workarounds

Use .NET 7?

Configuration

.NET SDK: 8.0.100-preview.3.23170.5

Other information

No response

Tagging subscribers to 'arch-android': @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

.NET 7 added a code path that uses System.Reflection.Emit for ConstructorInfo/MethodInfo for coreclr. This makes sense for throughput, scenarios like ASP.NET.

On mobile, however, we are more concerned about a fast startup. I found that we may have accidentally introduced this behavior for Mono (or at least Android) in .NET 8:

#72717

In .NET MAUI apps that heavily use things like data-binding, Microsoft.Extensions.DI, etc. It appears that this change noticeably slows down startup.

In my benchmark, I setup a "first run" / "cold start" scenario:

Version	Method	Mean	Allocated
.NET 7	ContructorInfo_Invoke	530.5 us	552 B
.NET 7	MethodInfo_Invoke	457.6 us	128 B
.NET 8	ContructorInfo_Invoke	607.7 us	4.09 KB
.NET 8	MethodInfo_Invoke	1,202.1 us	2.38 KB

/cc @steveisok

Reproduction Steps

Try my instructions here: https://github.com/jonathanpeppers/BenchmarkDotNet-Android/tree/System.Reflection

Expected behavior

We probably shouldn't hit the S.R.E codepath by default on Android.

We should have a flag to opt into it? It may be useful for some apps, although it appears to slow down startup in the apps I've tried.

Actual behavior

We hit the S.R.E codepath by default on Android.

Regression?

Yes, it appears .NET 7 does not have this issue.

Known Workarounds

Use .NET 7?

Configuration

.NET SDK: 8.0.100-preview.3.23170.5

Other information

No response

Author:	jonathanpeppers
Assignees:	-
Labels:	os-android, area-CoreLib-mono
Milestone:	-

[steveisok]

@lambdageek what are your thoughts?

[lambdageek]

Maybe we can have a heuristic: if SRE classes like DynamicMethod are already loaded and initialized for some other purpose, use the SRE invoke path. otherwise go via the runtime.

We could add a static flag somewhere in the invoke code and toggle it from the static cctor for ILGenerator, for example.

[steveisok]

@SamMonoRT can someone from your team take a look and maybe prototype @lambdageek's idea?

[jonathanpeppers]

Should these somehow use the existing feature switches?

• System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported
• System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeCompiled

https://github.com/dotnet/runtime/blob/main/docs/workflow/trimming/feature-switches.md

In theory, an MSBuild property would let users be able to opt into IsDynamicCodeCompiled (or some new feature switch).

[SamMonoRT]

@ivanpovazan - can take a look sometime next week.

[lambdageek]

Should these somehow use the existing feature switches?

• System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeSupported
• System.Runtime.CompilerServices.RuntimeFeature.IsDynamicCodeCompiled

These switches are used already. They disable the SRE codepath when we're on the interpreter or on fullaot, etc.

Don't we want the SRE path in the steady state on platforms where we have a JIT?

I assume the issue on Android is just that at startup we don't want to bother with loading SRE support for one-off callbacks. But presumably once the app is running, we want the SRE codepath?

I'm assuming the SRE codepath is faster in the steady state (I think we have microbenchmarks to back that up, right @SamMonoRT ?)

In theory, an MSBuild property would let users be able to opt into IsDynamicCodeCompiled (or some new feature switch).

I don't think this should be a user-visible switch - we should figure out how Android could have fast startup and fast steady state.

Or if SRE is never faster for mono, then we should disable the SRE Invoke machinery. Messing with IsDynamicCodeXYZ feature switches will have much wider impact (for example in Linq; in trimming; etc)