点击上方蓝字
关注我们
（本文阅读时间：15分钟)
接上篇内容 ，本篇文章将介绍：DependentHandle 现已公开、RyuJIT、即用型代码/Crossgen 2、.NET 诊断：EventPipe、SDK 的相关攻略 。
DependentHandle 现已公开
该 DependentHandle 类型现在是公共的 ， 具有以下 API 表面：

namespace System.Runtime { public struct DependentHandle : IDisposable { public DependentHandle(object? target, object? dependent); public bool IsAllocated { get; } public object? Target { get; set; } public object? Dependent { get; set; } public (object? Target, object? Dependent) TargetAndDependent { get; } public void Dispose; } } 它可用于创建高级系统 ， 例如复杂的缓存系统或 ConditionalWeakTable<TKey, TValue>类型的自定义版本 。 例如 ， 它将被 MVVM Toolkit 中的 WeakReferenceMessenger 类型使用 ， 以避免在广播消息时分配内存 。
▌可移植线程池
.NET 线程池已作为托管实现重新实现 ， 现在用作 .NET 6 中的默认线程池 。 我们进行此更改以使所有 .NET 应用程序都可以访问同一个线程池 ， 而不管是否正在使用 CoreCLR、Mono 或任何其他运行时 。 作为此更改的一部分 ， 我们没有观察到或预期任何功能或性能影响 。
RyuJIT
该团队在此版本中对 .NET JIT 编译器进行了许多改进 ， 在每个预览帖子中都有记录 。 这些更改中的大多数都提高了性能 。 这里介绍了一些 RyuJIT 的亮点 。
▌动态 PGO
在 .NET 6 中 ， 我们启用了两种形式的 PGO（配置文件引导优化）：

• 动态 PGO 使用从当前运行中收集的数据来优化当前运行 。
• 静态 PGO 依靠从过去运行中收集的数据来优化未来运行 。

动态 PGO 已经在文章前面的性能部分中介绍过 。 我将提供一个重新上限 。
动态 PGO 使 JIT 能够在运行时收集有关实际用于特定应用程序运行的代码路径和类型的信息 。 然后 ， JIT 可以根据这些代码路径优化代码 ， 有时会显着提高性能 。 我们在测试和生产中都看到了两位数的健康改进 。 有一组经典的编译器技术在没有 PGO 的情况下使用 JIT 或提前编译都无法实现 。 我们现在能够应用这些技术 。 热/冷分离是一种这样的技术 ， 而去虚拟化是另一种技术 。
要启用动态 PGO ， 请在应用程序将运行的环境中进行设置DOTNET_TieredPGO=1 。
如性能部分所述 ， 动态 PGO 将 TechEmpower JSON“MVC”套件每秒的请求数提高了 26%（510K -> 640K） 。 这是一个惊人的改进 ， 无需更改代码 。
我们的目标是在未来的 .NET 版本中默认启用动态 PGO ， 希望在 .NET 7 中启用 。 我们强烈建议您在应用程序中尝试动态 PGO 并向我们提供反馈 。
▌完整的 PGO
要充分利用 Dynamic PGO ， 您可以设置两个额外的环境变量：DOTNET_TC_QuickJitForLoops=1和DOTNET_ReadyToRun=0. 这确保了尽可能多的方法参与分层编译 。 我们将此变体称为Full PGO 。 与动态 PGO 相比 ， 完整 PGO 可以提供更大的稳态性能优势 ， 但启动时间会更慢（因为必须在第 0 层运行更多方法） 。
您不希望将此选项用于短期运行的无服务器应用程序 ， 但对于长期运行的应用程序可能有意义 。
在未来的版本中 ， 我们计划精简和简化这些选项 ， 以便您可以更简单地获得完整 PGO 的好处并用于更广泛的应用程序 。
▌静态 PGO
我们目前使用静态 PGO来优化 .NET 库程序集 ， 例如 R2R（Ready To Run）附带的程序集System.Private.CoreLib 。
静态 PGO 的好处是 ， 在使用 crossgen 将程序集编译为 R2R 格式时会进行优化 。 这意味着有运行时的好处而没有运行时成本 。 这是非常重要的 ， 也是 PGO 对 C++ 很重要的原因 。