Build Time Comparision

At yesterday’s flang technical call, we wanted to have an additional data point for the build time of flang itself, by also getting the compilation time using msvc.

Using my personal notebook with Intel Core i7-7700HQ CPU @ 2.80GHz, 16GB RAM, Windows 10 1909. I could not find a reliable way to get the user/system time for a process tree under Windows, so I am using wall clock time and single threads (ninja -j1). To keep the build time reasonable, I only timed compilation flang itself and its f18 executable (ninja says 130 tasks after touching every file in the flang subdirectory, consistent with every compiler). -DCMAKE_BUILD_TYPE=Release. I was using the computer while taking the time. Peak resident/working set size was determined using python psutil.

Msvc has parallelized its code generation and uses 4 threads by default. To make numbers more comparable, I have another run where I switched this off (/cgthreads1).


GCC 7.5 (Ubuntu 18.04.4, WSL)
Wall clock duration: 0:45:47
Peak compiler resident size: 4042.9 MiB (by cc1plus PFTBuilder.cpp)
Peak linker resident size: 151.8 MiB (by ld.lld f18)

Clang 11.0.0 (release build 3e94943d, WSL)
Wall clock duration: 1:42:22
Peak compiler resident size: 3266.0 MiB (by clang++ PFTBuilder.cpp)

Peak linker resident size: 260.7 MiB (by ld.lld f18)

MSVC 19.26.28806 (Visual Studio 2019 16.6.5 – current latest)
Wall clock duration: 0:59:26
Peak compiler working set: 7915.9 MiB (by cl.exe f18.cpp)

Peak linker working set: 747.9 MiB (by link.exe f18.exe)

MSVC /cgthreads1

Wall clock duration: 1:32:19

Peak compiler working set: 7918.3 MiB (by cl.exe f18.cpp)

Peak linker working set: 747.9 MiB (by link.exe f18.exe)

I also tried Intel icc, which unfortunately failed: tablegen does recognize its command line argument. I assume the cl::opt command line registration static initializer does not work.


Hi Michael,

Thanks for these numbers, this data is useful and seems to match what I
see on Linux.
To add another observation: the truly pathological linker case only
comes up in Debug builds rather than Release builds, which is when I
start to see peak linker resident usage of upwards of 8GB on Linux. I
wonder if this is the same on Windows too?

David Truby

Linking a debug build was always an issue under Linux, less so with msvc because

  1. Incremental linking
  2. Debug info not embedded into the binary, but a separate pdb file
  3. The pdb is built by another process (mspdbsrv.exe) that the compiler communicates to via IPC.

Item 2. can also be done with clang/gcc sing the -gsplit-dwarf flag -DLLVM_USE_SPLIT_DWARF=ON). Item 3 was discussed for clang at some point.