|
Of what relevance is MethodImplOptions.AggressiveOptimization nowadays. When searching through the runtime dotnet repo I can only find a few occurences. Benchmarking with and without AggressiveOptimization shows that is better not to use it. Are there any suggestions or thoughts about this? |
Replies: 2 comments · 1 reply
|
It helps in extremely niche scenarios where Tier 0 (on CoreCLR) is too slow or allocates too much, and it can't be crossgen'd due to cross-assembly types - though we might eventually work around that on the runtime side. Otherwise, it's a pure regression: there is no dynamic PGO, and it's highly likely that all statics aren't initialized at JIT time, meaning they are emitted with lazy-init helper calls, etc. Obviously, it has no impact on NativeAOT at all. Sometimes it might be used as a "don't use Dynamic PGO for this" hint, but there shouldn't be a good reason for that either. Basically, in the entire BCL there is just one usage (see #90965 and #90899) |
It helps in extremely niche scenarios where Tier 0 (on CoreCLR) is too slow or allocates too much, and it can't be crossgen'd due to cross-assembly types - though we might eventually work around that on the runtime side. Otherwise, it's a pure regression: there is no dynamic PGO, and it's highly likely that all statics aren't initialized at JIT time, meaning they are emitted with lazy-init helper calls, etc. Obviously, it has no impact on NativeAOT at all. Sometimes it might be used as a "don't use Dynamic PGO for this" hint, but there shouldn't be a good reason for that either.
Basically, in the entire BCL there is just one usage (see #90965 and #90899)