【译】A unit of profiling makes the allocations go away

　　在 Visual Studio 17.8 Preview 2 中，我们更新了单元测试分析，允许你在性能分析器中使用任何可用的工具——而不仅仅是仪表工具。有了这个更改，可以很容易地快速分析孤立的小工作单元，进行更改，然后重新度量和验证更改的影响。假设您有良好的测试覆盖率，这是利用现有资产来帮助优化应用程序性能的好方法。

谁动了我的奶酪?

　　在这个新版本中，我们更新了单元测试分析体验。以前，当在单元测试上下文菜单中选择 profile 时，它在 Instrumentation 工具下运行，并且您在运行结束时得到报告。

　　现在，当您选择一个 profile 时，Performance Profiler 启动页面将出现，您可以选择任何可用的工具。

　　这让您可以使用 .NET Object Allocation 工具来分析单元测试，以查看所有的分配以及它们来自哪里。这是减少不必要的分配并验证更改的好方法。

让我们减少一些分配吧！

　　现在我们可以使用任何工具了，让我们花5分钟看看我们是否可以从性能分析器中减少一些分配。首先，我有一个名为“VerifySimpleCallTree”的单元测试，我们使用它来验证我们的分析器是否正确地构建了一个调用树。在测试资源管理器中，我右键单击测试并选择“Profile”，得到 Performance Profiler，选择 .NET Object Allocation 工具，然后点击“Start”。从这里开始我的测试运行，一旦完成，我就会得到正常的分配报告，我可以用它来深入研究分配，看看我可以削减什么来减轻 GC 的负担。

　　当我浏览这些类型时，我注意到分配了一堆 Enumerators 。虽然这不是直接错误，但它确实看起来很奇怪。通过回溯，我可以看到这是来自我们的 JmcConfigurationService，并且查看代码，可以肯定枚举器是从 Any() 扩展方法创建的。

this.patternsLock.EnterReadLock();
try
{
    if (this.unknownModulePatterns.Any(t => t.IsMatch(moduleString)))
    {
        return JmcState.UnknownCode;
    }
    else if (this.systemModulePatterns.Any(t => t.IsMatch(moduleString)))
    {
        return JmcState.SystemCode;
    }
    else
    {
        return IsStringJmc(moduleString, this.excModulePatterns, this.incModulePatterns) ? JmcState.UserCode : JmcState.LibraryCode;
    }
}
finally
{
    this.patternsLock.ExitReadLock();
}

　　通过使用静态局部函数快速重写，我们可以删除枚举数并减少分配。

this.patternsLock.EnterReadLock();
try
{
    if (CheckMatch(this.unknownModulePatterns, moduleString))
    {
        return JmcState.UnknownCode;
    }
    else if (CheckMatch(this.systemModulePatterns, moduleString))
    {
        return JmcState.SystemCode;
    }
    else
    {
        return IsStringJmc(moduleString, this.excModulePatterns, this.incModulePatterns) ? JmcState.UserCode : JmcState.LibraryCode;
    }
}
finally
{
    this.patternsLock.ExitReadLock();
}

static bool CheckMatch(List patterns, string moduleStr)
{
    foreach (var pattern in patterns)
    {
        if (pattern.IsMatch(moduleStr))
        {
            return true;
        }
    }

    return false;
}

　　在单元测试上重新运行分析器，我可以验证并得出结结论：实际上，我已经删除了这些不必要的分配，并帮助减少了 GC 的负担。

　　虽然这个小调整不会让我的应用神奇地快20%，但随着时间的推移慢慢减少不必要的分配是逐步提高应用性能的好方法。有了新的单元测试分析，就可以很容易地处理现有的测试资产，然后验证更改是否产生了预期的影响。

让我们知道你的想法！

　　使用单元测试进行独立性能分析的能力令人敬畏。通过隔离特定的代码区域，很容易获得良好的前后跟踪，以比较和查看性能优化的影响。我们热切欢迎任何聪明的想法，看法，或有价值的见解，我们洗耳恭听!不要隐瞒，请随时与我们分享吧。

 

原文链接：https://devblogs.microsoft.com/visualstudio/a-unit-of-profiling-makes-the-allocations-go-away/