Flip logic for enabling VXSort in the GC #118633
Conversation
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.
There was a problem hiding this comment.
Pull Request Overview
This PR flips the default behavior for VXSort in native AOT compilation by disabling it in the default blended mode and only enabling it when explicitly optimizing for speed. The change addresses concerns about binary size impact - VXSort adds 115KB and can represent 11% of a hello world native AOT binary.
Key changes:
- Changes default VXSort behavior from enabled to disabled in blended optimization mode
- VXSort now only enables when
OptimizationPreferenceis set toSpeedor when explicitly enabled viaIlcEnableVxsort - Replaces the size-optimization exclusion logic with speed-optimization inclusion logic
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| Microsoft.NETCore.Native.Windows.targets | Updates Windows native AOT build logic to disable VXSort by default and enable only for speed optimization |
| Microsoft.NETCore.Native.Unix.targets | Updates Unix native AOT build logic to disable VXSort by default and enable only for speed optimization |
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
|
Makes sense to me. The binary size test needs updating. |
Good problem to have! |
VxSort is helpful for apps with heavy allocations per request, dont think the standard asp.net benchmarks will show any benefits. Agree to keep it off by default -- do we know the split of apps built with blended, speed or size? |
The best I have is a non-scientific Github search:
So about 1% of users set Speed, 1% set Size and 98% leave at the default. |
For native AOT we document 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 when we optimize for speed. We link out VXSort when optimizing for size. Maybe this is not something that should be part of the blended default.
dotnet new console --aotanddotnet publishthe hello world, 11% of the output binary is VXSort (!)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.
Cc @dotnet/ilc-contrib @dotnet/gc