【发布时间】：2020-08-19 09:50:55
【问题描述】：
MethodImplOptions.AggressiveOptimization 到底是做什么的？
Microsoft's documentation 并没有告诉我太多。在什么情况下可以派上用场？
【问题讨论】：
标签： .net optimization .net-core documentation jit
【发布时间】：2020-08-19 09:50:55
【问题描述】：
我会在.net core github 或release notes 上而不是在文档中查找更多详细信息（如果您正在寻找的话）。
让我们从后者开始。对于 .net core 3.0，我们可以找到以下条目：
完全优化的 JIT 生成更高质量（或更优化）的代码的速度更慢。对于不使用 Quick JIT 的方法（例如，如果该方法具有 MethodImplOptions.AggressiveOptimization 属性），则使用完全优化的 JIT。
因此，首先，我们知道如果一个方法被标记了这样的属性，它应该使用完全优化的 JIT 进行 JIT，这可能会产生更好、更优化的代码 - 但会花费更多时间来编译。
现在让我们关注 github，看看我们可以在那里找到什么。
关于这个的讨论在这个ticket 中完成，它提供了更多关于这个主题的细节。
可以在 MethodImplAttribute 中使用该标志来指示该方法包含热代码：
- 对于分层，它可能会导致第 1 层 JIT 立即用于方法[...]
- 它可以让 JIT 花费更多的 JIT 时间来生成更好的代码，例如更积极地内联到函数中
由此我们可以得到答案，在哪些情况下可以使用它，以及它在下面做什么。
在我们处理热路径代码的情况下 - 此属性有助于 JIT 生成更快、更优化的代码，而不是进行分层编译。如果运行时检测到它实际上处于热路径上，则在开始时使用更多时间可以节省时间。
您可以阅读有关此标志的其他用法的有趣讨论。
但最终的真相（我希望）和提交与此讨论相关联，因此我们可以查看它们。从这些提交和提交消息中，我们可以了解到这实际上是分层编译和 JIT 正在发生的事情（至少这是我能看到的）。
【讨论】：
-
所以这个标志只对分层编译有用，否则什么都不做？
-
这至少是我能找到的。
-
它目前做了两件事：(1) 使方法不适合进行 prejitting 和 (2) 使方法不适合分层编译。最终结果是该方法在第一次调用时总是被jited，并且jitted 的代码得到了优化。仅当您发现为该方法运行 prejitted 或 Tier0 代码会导致不良影响（性能损失或额外分配）时，才使用此标志。如果您没有看到这些不良影响，您最好不要使用该标志；常规的 Tier1 代码通常会比 AggressiveOptimization 代码执行得更好。
-
@Redhouane 你应该知道什么是你的热门代码（分析？）。更多关于 JIT 如何知道哪些方法是更好的 Jitting 候选方法的更多信息，请参见 here。
-
jit 通过正常的 Tier1 rejitting 生成的代码通常比使用 AggressiveOptimization 生成的代码优化得更好。这里的关键区别在于该方法的优化版本何时被抖动。对于正常的 Tier1 jitting 发生在进程生命周期的后期，因此 jit 可以更好地利用已经初始化的类 - 因此普通的 Tier1 jitted 代码不需要那么多的类初始化检查，并且可以合并来自的只读静态变量的值和类型初始化的类。具有 AggressiveOptimization 的方法会更早地被 jitted，因此在这里会丢失。