漫漫开发路@Insights找到编译过程中的瓶颈，使用C＋Build( 二 ) 找到编译时间的瓶颈C++BuildInsights提

>编译器或者链接器的版本。
>当前工作目录
>重要的环境变量，例如PATH或_CL_ 。
>编译过程中使用到的完整命令行，包括来自响应(.RSP）文件或环境变量的参数。
请注意，如果命令行或环境变量太长，则有时会在多个条目中显示它们。

文章图片
预设4:ActivityStatistics
ActivityStatistics预设显示BuildExplorer视图跟踪的所有工程编译活动的汇总统计信息。例如，使用它可了解所有链接器和编译器调用的总持续时间，或者判断工程的编译时间是否受到了解析或代码生成的影响。在此预设下，视图的图形部分显示每个活动的活动时间，而表格部分显示合计的持续时间总计，可以通过活动的详细信息来查看该活动的所有实例。图形，表格和下拉列表的界面如下图所示。

文章图片

文章图片

文章图片
一个实际案例
在这个实际案例研究中，我们使用了来自GitHub的真实开源项目，并展示了如何发现并修复工程编译时间的瓶颈。
具体步骤如下：
1.搜索并[GitforWindowsGitHub]仓库到本地。
2.切换到[vs/master]分支。
3.从工程的根目录开始，打开[gitgit.sln]解决方案。
4.生成x64版本配置。这将提取所有程序包依赖关系并进行一次完整的工程编译。
5.获取有关工程编译的信息：
5.1在PATH上使用vcperf打开具备管理员权限的命令提示符。
5.2运行以下命令:vcperf/startGit
5.3在VisualStudio中重新编译[x64Release]版本的[gitgit.sln]解决方案。
5.4运行以下命令：vcperf/stopGitgit.etl 。这将在git.etl文件中保存工程编译的所有信息。
6.在WPA中打开编译信息。
我们使用BuildExplorer视图的Timelines预设，并立即注意到了长时间运行的调用似乎是工程编译开始时的瓶颈。如下图所示：

文章图片
我们查看该调用的属性，并注意命令行中没有使用到/MP编译开关，这个开关用来启用编译器的并行执行。我们还从[WorkingDirectory]属性中注意到，正在编译的项目称为[libgit] 。

文章图片
我们可以在VisualStudio里为工程libgit上启用/MP编译开关，如下图所示：

文章图片
接下来，我们可以使用本节开头的步骤来重新捕获一次工程编译信息，以此来确认我们是否已经解决了这个编译瓶颈问题。我们发现：构建时间从大约120秒减少到80秒，编译性能提高了33% 。

文章图片
通过C++BuildInsightsSDK来定位工程编译瓶颈
使用vcperf和WPA手动执行的大多数分析任务也可以使用C++BuildInsightsSDK以程序化的方式执行。
为了说明这一点，我们准备了[BottleneckCompileFinder]SDK示例。当找到未使用/MP编译开关的编译器调用瓶颈时，它将发出警告。
如果没有其他编译器或连接器调用同时被调用，则该调用被视为瓶颈。
让我们重复上一节中的Windows版Git案例研究，但是这次通过使用BottleneckCompileFinder来查看发现的编译瓶颈。