-
|
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? |
Beta Was this translation helpful? Give feedback.
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) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
@EgorBo @mg1986jp : Thanks a lot for your detailed explanation. That helped ;-) |
Beta Was this translation helpful? Give feedback.
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)