Build times

I build firefox and llvm all the time. I recently built chromium to track a llvm bug. It is interesting to see how different build systems behave.

For llvm I started using configure+make, but had switched to cmake+make for some time. Since cmake 2.8.8 one can use cmake+ninja too on linux.

To build chromium I used gyp+ninja. The chromium developers had a big influence in these projects to speed up their builds.

The build system of firefox is a fairly rusty configure+make, with multiple passes during a build.

So, how do they compare? I did all the builds with -O3 -g and a fixed version of clang on a 4 core (8 threads) i7 860. I benchmarked both a full build (starting with an empty build dir) and a nop build (nothing changed, hot cache).

The total .o produced adds up to 1937MB for llvm+clang. The build times were:


cmake+make full: 9m45.737s
cmake+ninja full: 9m38.029s
configure+make full: 11m57.156s

cmake+ninja nop: 0m0.120s
cmake+make nop: 0m2.166s
configure+make nop: 0m2.709s
The configure builds also compile the unit tests, which the cmake ones only do it when "building" the check target.

It is interesting to see that cmake produces faster Makefiles than the mostly hand written ones created by configure. Cmake's support for ninja also makes it possible to directly show ninja advantages over make. While all the nop build times are small, they are noticeable during a normal edit+compile cycle and ninja is a welcome improvement.

For firefox the .o files add up to 1775 MB, which is fairly small (maybe because we don't use a lot of templates?). The full build took 14m and a nop build took 57.9s.

For chromium I built "only" the chrome target. Clang is know to produce fat debug info for chromium, and the total .o files add up to 6417 MB! The full build took 30m, but a nop build took only 0.74s.

In here the advantage of having a better build system should be obvious to anyone. While chromium's full build is 2.15x slower than firefox's, a nop build is 78.2x faster! That is really noticeable during development. No incremental build of firefox can be faster than 57.9s, which means that in practice almost all of them will be over a minute. That is an annoying pause while trying different ways to solve a problem or adding debug checks.

Firefox's incremental build is so slow that I noticed some of the more senior developers have part of the dependency graph in their heads. Instead of letting the build system figure it out, the will do build with

$ cd obj/some_dir
$ make foo.o
$ cd ../toolkit/library
$ make libxul.so
...

Which is unfortunately very error prone since it is easy to miss a dependency.
Shared publiclyView activity