Repository navigation
Reduced .NET8 R2R performance #96242
Description
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.
Activity
[-]Reduce .NET8 R2R performance [/-][+]Reduced .NET8 R2R performance [/+]janvorli commentedon Dec 27, 2023
cc: @trylek
JensNordenbro commentedon Feb 26, 2024
Any comments on this issue?
steveisok commentedon Jun 21, 2024
@ivdiazsa please run this through the ringer and see if you get the same results.
AndyAyersMS commentedon Aug 9, 2024
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 commentedon Aug 9, 2024
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 commentedon Aug 9, 2024
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?
4 remaining items
jkotas commentedon Aug 9, 2024
@ivdiazsa I see that you have modified the milestone to 10.0. The
PointDtype is very simple. It looks like a pretty bad crossgen2 bug to me if we are not able to load it. You may want to reconsider.JensNordenbro commentedon Aug 10, 2024
@ivdiazsa, for us, labling this 10.0, makes the prospect of moving from net6.0-lts problematic. Either we stay=) insecure or we move to net8.0 =) slow.
steveisok commentedon Aug 10, 2024
This is something we'll prioritize now and is highly likely to make its way back to net8.
ivdiazsa commentedon Aug 10, 2024
Thanks a lot for the detailed explanation and guidance @jkotas. Will prioritize it and get to investigate it on Monday.
ivdiazsa commentedon Aug 15, 2024
@JensNordenbro Hi, we've been researching and are currently developing a fix. While investigating, we found that your repro app has an
[assembly: Guid("Guid goes here")]annotation in Properties/AssemblyInfo.cs file. Considering you also have[assembly: ComVisible(false)], is there a reason you might need the Guid? I ask because due to where the bug lies in the type system, if you remove that Guid clause, the regression disappears. I got ~5ms on my testing machine, which is fairly similar to .NET 6 and .NET 7. Would this work as a temporary workaround?JensNordenbro commentedon Aug 16, 2024
Hi @ivdiazsa !
I will try to schedule a real investigation on the real app but I think it might take some time before we get to that. (summer, ...)
Nice to see progress!
ivdiazsa commentedon Aug 19, 2024
Hi @JensNordenbro! We've finished working on the fix and will soon begin working on the backport to .NET 8.
ivdiazsa commentedon Aug 21, 2024
The backport has been successfully completed. The fix will be available on the .NET 8.0.10 release.
JensNordenbro commentedon Aug 23, 2024
Thanks @ivdiazsa!
Once started, this was quick 😄