Reduced .NET8 R2R performance

[JensNordenbro]

Description

On arm64, using PublishReadyToRun on the attached project; you will get reduced performance using .NET8 (not present in NET7, NET6).

dotnet publish .\Arm64Net8JitError.csproj -f net6.0-windows -r win-arm64 -c Release --no-self-contained -p:PublishReadyToRun=true -o error_62_net6
 
dotnet publish .\Arm64Net8JitError.csproj -f net8.0-windows -r win-arm64 -c Release --no-self-contained -p:PublishReadyToRun=true -o error_63_net8

On my machine:
NET6: 10ms
NET8: 650ms

To help you guys get started, we have extracted a minimal reproduce project that triggers the error from a real application if you wonder why the app has no apparent purpose.

Changing from struct to class on Point2D will remove the problem.
Arm64Net8JitError.zip

Reproduction Steps

Start program published with parameter PublishReadyToRun:true and press the one button and get a messagebox with the init time to spot the difference.

Expected behavior

Non regressed performance.

Actual behavior

Really bad performance -> real world applicaton starts 10 times slower. Attached benchmark app is even slower than that.

Regression?

Yes, works in NET6.0, NET7.0

Known Workarounds

Convert Point2D struct to class instead.

Configuration

See description.

Other information

We target imx8MPlus.

[janvorli]

cc: @trylek

[JensNordenbro]

Any comments on this issue?

[steveisok]

@ivdiazsa please run this through the ringer and see if you get the same results.

[AndyAyersMS]

Looks like in .NET 8 there is one method with unusually long jitting time (found via the jit stats tab of a perfview run) that likely accounts for the startup time issue you're seeing:

that method does not appear in the .NET 6 jit stats, so presumably it was prejitted in .NET 6 but not in .NET 8.

So the question is, why doesn't that method get prejitted in .NET 8? That will take a bit more digging.

[AndyAyersMS]

Seems like per r2r dump the method does get prejitted, so perhaps the runtime is deciding the method can't be used for some reason? (runtime might also toss the entire R2R payload).

There is an ETW bit in the method load event for this, but perfview doesn't parse it yet in the raw payload.

[ivdiazsa]

Thank you very much for the insight Andy. What might be the possible reasons the runtime might decide that and discard everything? And how would we investigate such a case?