分析单元会使分配消失
在VisualStudio17.8Preview 2中，我们更新了单元测试分析，允许您使用性能分析器中的任何可用工具，而不仅仅是检测工具。有了这个更改，很容易单独快速分析小的工作单元，进行更改，然后重新测量和验证更改的影响。假设您有良好的测试覆盖率，这是一种利用现有资产帮助调整应用程序性能的好方法。
谁动了我的奶酪？
通过这个新版本，我们更新了单元测试分析经验。以前，当在单元测试的上下文菜单中选择概要文件时，它在Instrumentation工具下运行，并且在运行结束时得到报告。
现在，当您选择一个配置文件时，将显示Performance Profiler启动页面，您可以选择任何可用的工具。
这使您可以使用执行类似于分析单元测试的操作。NET对象分配工具查看所有分配及其来源。这是一种减少不必要的分配，然后验证更改的好方法。
让我们减少一些分配！
现在我们可以使用任何工具了，让我们花5分钟看看是否可以从性能分析器中调整一些分配。首先，我有一个名为“VerifySimpleCallTree”的单元测试，我们使用它来验证我们的探查器是否正确地构建了一个调用树。在测试浏览器中，我右键单击测试并选择“Profile”，显示Performance Profiler，选择。NET对象分配工具，然后单击“开始”。从这里，我的测试运行并完成后，我得到了正常的分配报告，我可以使用该报告深入研究分配情况，并查看可以修改哪些内容以减轻GC的负担。
当我仔细查看这些类型时，我注意到分配了一堆枚举器。虽然这并不是马上就错了，但看起来确实很奇怪。通过回溯，我可以看到这是来自我们的JmcConfigurationService，并且通过查看代码，可以确定正在从Any（）扩展方法创建枚举器。
this.patternsLock（此模式锁定）。进入ReadLock（）；尝试{if（this.unknownModulePatterns.Any（t=>t.IsMatch（moduleString））{return JmcState。未知代码；}else if（this.systemModulePatterns.Any（t=>t.IsMatch（moduleString）））{返回JmcState。系统代码；}其他的{返回IsStringJmc（moduleString，this.excModulePatterns，this.incModulePatterns）？Jmc州。用户代码：JmcState。图书馆代码；}}最后{this.patternsLock（此模式锁定）。ExitReadLock（）；}
通过使用静态局部函数进行快速重写，我们可以删除枚举器并减少分配。
this.patternsLock（此模式锁定）。进入ReadLock（）；尝试{if（CheckMatch（this.unknownModulePatterns，moduleString））{返回JmcState。未知代码；}else if（CheckMatch（this.systemModulePatterns，moduleString））{return JmcState。系统代码；}其他的{返回IsStringJmc（moduleString，this.excModulePatterns，this.incModulePatterns）？Jmc州。用户代码：JmcState。图书馆代码；}}最后{this.patternsLock（此模式锁定）。ExitReadLock（）；}静态bool CheckMatch（列表模式，字符串模块Str）{foreach（模式中的var模式）{if（pattern.IsMatch（moduleStr））{返回true；}}返回false；}
在单元测试中重新运行分析器，然后我可以验证是的；事实上，我已经删除了这些不必要的分配，并帮助减轻了GC的负担。
虽然这个小小的调整不会让我的应用程序神奇地快20%，但随着时间的推移，慢慢减少不必要的分配是逐步提高应用程序性能的好方法。使用新的单元测试概要分析，可以很容易地对现有的测试资产进行分析，然后验证更改是否产生了所需的影响。
让我们知道你的想法！
使用单元测试进行独立性能分析的能力非常棒。通过隔离特定的代码区域，很容易获得良好的前后跟踪，以比较和查看性能优化的影响。我们热忱欢迎任何好主意、想法或有价值的见解，我们洗耳恭听！不要犹豫，在这里与我们分享链接.
尼克·卡平斯基
Visual Studio Profiler首席软件工程师主管
