Compile-time measurements in Chromium

Clang Frontend
1

Hello all,

I have been measuring compile times for Chromium using different
versions of GCC and Clang, and I thought it might be a good idea to
share the results in case someone else finds them interesting.

Two measurements were conducted: average compile time for a file in a
set of 100 randomly selected translation units, and average compile
time for a file in the set of the 10 translation units that are
slowest to compile.

Each translation unit was first compiled once for warm-up, and then
compiled five times using "perf stat -r5" [1]. The means of the wall
clock compile times were then added together and divided by number of
translation units.

The measurements were conducted on an x64 machine running Ubuntu
GNU/Linux. CPU frequency scaling had been disabled.

The GCC versions used were 4.4.6, 4.6.2, and 4.7 built from svn
revision r183805.
The Clang/LLVM versions used were 3.0, and 3.1 built from svn revision r149506.
The Chromium version used was r119678. Source is available from [2].

The flags used were -fsyntax-only -O0, -O0, -O0 -g, -O2, -O2 -g. Note
that the -fsyntax-only results are incomparable between compilers
since the flag means different things for GCC and Clang.

GCC was configured with "--enable-languages=c,c++ --disable-multilib
--enable-checking=release"
Clang was configured with "--enable-optimized --disable-assertions"

Attached are plots of the results and the full output from running the
measurements.

These are the average compile times for compiling a file in a set of
100 randomly selected files: (time values in seconds)

            gcc 4.4 gcc 4.6 gcc 4.7 clang 3.0 clang 3.1
-fs-o -O0 0.450 0.458 0.501 0.449 0.439
-O0 0.624 0.631 0.684 0.504 0.494
-O0 -g 0.722 0.727 0.781 0.661 0.653
-O2 0.811 0.803 0.874 0.603 0.597
-O2 -g 0.916 0.979 1.06 0.809 0.809

These are the average compile times for compiling a file in the set of
the 10 files that are slowest (as when compiled with gcc 4.4 using
-O2) to compile:

            gcc 4.4 gcc 4.6 gcc 4.7 clang 3.0 clang 3.1
-fs-o -O0 2.18 1.70 1.86 1.70 1.66
-O0 5.87 5.33 5.71 2.90 2.85
-O0 -g 6.71 6.19 6.61 4.00 4.08
-O2 11.9 10.8 12.0 6.72 6.80
-O2 -g 13.2 13.6 15.1 9.57 9.78

Thanks,
Hans

[1] perf-stat(1) - Linux man page
[2] Get the Code: Checkout, Build, & Run Chromium

compile_time.png
compile_time.png800×600 5.19 KB

compile_time_top10.png
compile_time_top10.png800×600 5.2 KB

measurements.log.gz (28.9 KB)

measurements_top10.log.gz (4.07 KB)

2

Hi,

nice numbers :slight_smile: One thing to keep in mind is that these are
compile-time numbers, but the object files generated by clang tend to
take ~20% longer to link than the ones generated by gcc, due to chubby
debug information.

I did incremental builds (touch one file, measure rebuild time – this
measures almost exclusively ld time) of the chrome binary in several
scenarios. In debug builds, the object files generated by clang take
up to 6 seconds longer to link into a final binary (36s instead of
30s, or in with a shared library build, 31s instead of 27s). In
release builds, there's no big difference.

So while compiling with clang is faster, linking the resulting object
files currently takes longer.

Nico

ps: Raw numbers (each is the min of 3 runs):

Chrome incremental build times (ninja, gold on by default, debug
builds, gcc4.4, chromeclang)
gcc
touch file in net (net/base/mime_util.cc) 29.4s
touch file in browser (c/b/u/g/chrome_gtk_frame.cc) 32.8s

clang
touch file in net 35.9s
touch file in browser 36.3s

gcc component build (libv8.so instead of libv8.a etc)
touch file in net 26.5s
touch file in browser 8.7s

clang component build
touch file in net 30.8s
touch file in browser 10.6s

(release builds)
gcc
touch file in net 6.4s
touch file in browser 5.9s

clang
touch file in net 6.3s
touch file in browser 6.2s

gcc component
touch file in net 6.7s
touch file in browser 3.1s

clang component
touch file in net 6.6s
touch file in browser 3.2s

3

Chubby or different? I know that gcc uses more of the dwarf standard for
types than clang does. I'd love to see some of the differences if you
could get me some bug reports :slight_smile:

-eric

4

One way to look at that is as an opportunity: if we fix the debug info bloat, that will surely speed up compile times (particularly -O0) even more. As it turns out, Eric is working on this exact area (shrinking debug info for C++ apps).

Eric, can you talk about some of the things you've observed and your possible approaches to tackle this?

-Chris

5

All data I have at the moment is "linking is slower" and the 10k .o
files generated by the two compilers. I filed http://llvm.org/PR11941
as tracking bug, I'll try to come up with some interesting .o files
and will post more information on that bug.

Nico

6

Going over some old email and noticed this. Have you tried -gdwarf-4
with gcc? I should reduce size of the debug information a bit.

Cheers,
Rafael

7

Thanks for the suggestion! Most of our bots are still on gcc 4.4. I'll
try once we're one 4.6 (some time this year).

Nico