　　在 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;
}