You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Flip logic for enabling VXSort in the GC (#118633)
For native AOT we [document](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/optimizing) three build modes: a blended default, optimized for size, and optimized for speed.
Typically, optimize for speed is needed to get as closed as possible to CoreCLR-JIT performance (e.g. optimize for speed is the only mode that enables Tier-1 inliner in the JIT). The blended default gets close, but this gives an extra percent or two in throughput at the cost of more size.
The VXSort code and table costs 115,712 bytes.
We currently compile with VXSort enabled in blended mode and optimize for speed. We link out VXSort when optimizing for size. Maybe this is not something that should be part of the blended default.
* When you do `dotnet new console --aot` and `dotnet publish` the hello world, 11% of the output binary is VXSort (!)
* Even in more significant apps (e.g. a simple Kestrel host), VxSort is still a single-digit percentage of the app.
* I was not able to measure improvement with VxSort on real world apps that I tried (native AOT compiled ILC, benchmarks we use in ASP.NET labs).
I'm leaning towards disabling this on blended builds.
Our default guidance if someone is not happy with native AOT TP is to switch to Speed optimized builds, so if there's a problem because of this being off, our default guidance would resolve this right away without even having to profile and root cause the problem to sorting. I think using VxSort in the Speed optimization mode only is the right default.
0 commit comments