{"id":29790,"date":"2021-11-19T09:41:12","date_gmt":"2021-11-19T09:41:12","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=29790"},"modified":"2023-12-06T02:25:04","modified_gmt":"2023-12-06T02:25:04","slug":"cpp-build-throughput-investigation-and-tune-up","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/cpp-build-throughput-investigation-and-tune-up\/","title":{"rendered":"C++ build throughput investigation and tune up"},"content":{"rendered":"

Building C++ code is a complex process, launching many build tools in parallel and often running for a long time. It is always desirable to make it faster, but also a challenge to understand what the most effective way would be to achieve this.<\/p>\n

We\u2019d like to share some techniques we use to get a “bigger” picture of the build, as well as tools that can help to see what is taking time in a particular part of the build. We\u2019ll also talk about MSBuild project options which can improve build parallelism without overwhelming the system, as well as other (not immediately obvious) options which might affect build throughput.<\/p>\n

This blog is more like a list of what is currently available, full of instructions and details. Some of the suggestions should be useful for any C++ build, but most of the measurements and tuning options are for MSBuild based projects (vcxproj).<\/p>\n

As any performance improvement starts with the measurement, here we are \u2013 measure your build.<\/p>\n

Note that the total build time can vary quite noticeably between several identical builds on the same machine \u2013 the system is adjusting to the active processes. So, if you compare builds before and after making some options changes, it is more reliable to run the build several times and get the average. It is also helpful to measure not only the total build time but get more detailed information, so if you get a surprising result, you can figure out why it happened. For MSBuild we recommend running it on the command line and collecting a binary log<\/a>.<\/p>\n

Measure your build time using MSBuild Performance Summary<\/h2>\n

If your build is MSBuild based, the first thing to do when investigating build performance is to see which projects and which tasks\/targets inside the projects are taking most of the build time. The performance summary data is also very useful for comparing builds using different options.<\/p>\n

To get a performance summary for your full build, you can do the following: open a Developer (or MSBuild) Command Prompt and run the build of your solution with the following options (replace Configuration and Platform values with the ones your solution actually has):<\/p>\n

msbuild \/m \/t:clean \/p:Configuration=\"Debug\";Platform=\"x86\" YourSolution.sln \r\nmsbuild  \/m \/fl  -flp:PerformanceSummary;v=q;LogFile=Perf.log \/p:Configuration=\"Debug\";Platform=\"x86\" YourSolution.sln\r\n<\/pre>\n
The “quet” or “minimal” verbosity setting (-flp:PerformanceSummary;v=q<\/code>) is recommended as console logging itself takes noticeable time. But you can set the verbosity to other levels if you want more build info in the Perf.log. You can also add \/detailedSummary<\/code> to see msbuild.exe nodes utilization<\/a>).<\/p>\n
The same information can be extracted from a binary log. We recommend creating binary logs when investigating your builds. To create a binary log, run:<\/p>\n
msbuild \/m \/t:clean \/p:Configuration=\"Debug\";Platform=\"x86\" YourSolution.sln \r\nmsbuild \/m \/bl:build.binlog \/p:Configuration=\"Debug\";Platform=\"x86\" YourSolution.sln<\/code><\/pre>\n
To extract the perf info into Perf.log, run:<\/p>\n
msbuild -noconlog -flp:PerformanceSummary -flp:v=q  build.binlog\r\nren msbuild.log Perf.log<\/code><\/pre>\n
You can also enable “Build Timings” for VC projects in the IDE by setting “Tools\/Options\/Projects and Solutions\/VC++ Project Settings\/Build Timings” = “Yes”. This will create the Perf Summary for each project, but not for the whole solution build. Thus, using the command line is better to see the “whole picture”.<\/p>\n
In the Perf.log you\u2019ll find times (in ms) it took to build the whole solution, each project (in the time increasing order) and commutative time of all targets and tasks (also in the time increasing order). Note that project build time and some targets (like ResolveProjectReferences target) include the wait for referenced projects to be built. You can use the Timeline tab of the binlog viewer to see if other projects were built as a part of a particular project build.<\/p>\n
For a solution containing mostly C++ projects, cl and link would usually be the tasks taking most of the time:<\/p>\n
Project Performance Summary:\r\n\u2026\r\n    1100252 ms  d:testMySolution.sln          1 calls \uf0df solution build time (msbuild \/m)\r\n\r\nTask Performance Summary:\r\n\u2026\r\n     22495731 ms  Link    250 calls \r\n    152500624 ms  CL      250 calls <\/code><\/pre>\n
The task time is the sum of all times the task was executing for all projects and thus it can be bigger than the total build time. For CL and Link tasks their time is very close to the cl.exe and link.exe time.<\/p>\n
Use Build Insights to see the build timeline for cl.exe and link.exe<\/h2>\n
Most of the C++ builds time is usually spent in the compiler. To visualize what is going on during the build, see the processes running in parallel and pivot on the parts that take most of the time, you can use the Build Insights<\/a> tool.<\/p>\n
\"\"<\/a><\/p>\n
Change options to improve C++ build throughput<\/h2>\n
There are many parameters which can affect build throughput and different codebases can benefit from different sets of options. Here we’ll talk about antivirus and project settings which are easy to change and which can potentially greatly improve your build throughput.<\/p>\n
1. Check your antivirus settings<\/h3>\n
C++ builds produce a lot of intermediate files and we often see the file system as a bottleneck there. With your antivirus scanning all build outputs, the problem is greatly amplified.<\/p>\n
Windows Defender Antivirus automatically excludes most of the common build tools when they are found in the default install locations. But if you install Visual Studio in a custom location or use many additional build tools, your build throughput might be affected.<\/p>\n
To see if Windows Defender scans are impacting your build, you can use Performance Analyzer for Microsoft Defender Antivirus<\/a>. The tool collects minimal data so you can run it for a good chunk of your build (10-20 min is usually enough) if not the whole build. We recommend closing all application unrelated to the build before collecting the data to avoid seeing unrelated to build processes in the report.<\/p>\n
To collect the data and see the affected build processes:<\/p>\n