Windows build sadness aside, as I went back to my old standby, Linux, I started to wonder about its build times. Am I doing my absolute best here? Lets do some tests. I’ve been using Clang ever since I need to do asan builds — yeah, yeah I know GCC supports this as of version xyz, but I also get fun things like our static analysis plug-in and pretty error messages.

As an aside: to install Clang I just downloaded the x86_64 Ubuntu build from LLVM’s official site. Nice and easy. For GCC builds go to the gcc site, check out their sweet binaries page where they let you know you can build it yourself you filthy animal and if you’d please download the source from a mirror that’d be great. If we’re evaluating on website alone GCC has already lost.

So the results of doing clean builds, no ccache:

Compiler	Clobber build time
clang-3.9.0	18 min
gcc-5.4.0	21 min
gcc-6.3.0	22 min

Build system specs: Ubuntu 16.04 LTS, 8 core Intel Core i7-4770 CPU @ 3.40GHz, 32 GB RAM, SSD, example of .mozconfig used.

Why those versions? I was already using clang 3.9.0 (and it was the latest release at the time), gcc 5.4.0 is what ships with Ubuntu 16.04, gcc 6.3.0 is the latest release.

Now you may argue that the resulting executable of foo bar baz is going to be smaller/faster/better. And I’d argue as a dev I don’t care. I just want to build quickly so I can run my test and repro a bug. Generally speaking all my builds are debug, asan-enabled, dmd-enabled. They’re never going to run fast.

I’d love to hear your thoughts on how to get optimal build times of Firefox on all platforms. Maybe I can build with better settings — for GCC I just used a vanilla config I found on another blog. I tried doing a PGO build of clang trained on building Firefox, but I ended up getting worse times with that. Odds are I was doing it wrong, but it would be pretty cool if Mozilla could produce them in our build infrastructure; I filed bug 1326486 for this.

It would be interesting to see the gcc and llvm folks use our codebase as a testing ground for build time performance — maybe it’s time to fire up arewecompiledyet.com.

The Tragedy

Recently I was looking into doing more dev on a Windows machine — you know, because basically all our users on are on Windows — and ran into the sad, sad fact that a clean build is going to take me 40 minutes on a brand new “pro-level” laptop. That’s just unacceptable. I filed a bug for that, the response was roughly “yeah we know, get a better machine” and was closed as invalid. I guess I get it, as far as a short term solution that makes sense, but this is pretty sad. It’s sad because on my 3 year old MacBook Pro I get 22 minute clean build for OSX. On my Linux desktop with similar specs I’m seeing 18 minute builds (this is without ccache).

System specs:
– Win10 laptop, Intel Xeon E3-1505 M @ 2.80GHz, 32 GB RAM, SSD
– OSX 10.12.1 laptop, Intel Core i7-4960HQ @ 2.6G0Hz, 16 GB RAM, SSD
– Ubuntu 16.04 desktop, Intel Core i7-4770 CPU @ 3.40GHz, 32 GB RAM, SSD

I should note we’re talking about clobber builds here for a platform dev poking around in C++. A lot of work has been done to make builds for frontend folks super fast with artifact builds (we’re talking a minute or two). We could also look at iterative builds, but often I’m working in heavily shared files that it doesn’t really matter (strings etc).

Not all is lost

It sounds like there’s some work to make it better although I don’t have any bug numbers, and have no clue what the priority is. It was also pointed out that sccache is going to work locally on Windows which should be a big improvement, it will be interesting to see some actual numbers.

I’m not sure if there’s more I can do to improve things as-is, here’s what I’ve done so far:
– Disabled malware scanning for my dev directory
– Configured the laptop to “performance” mode

Just piping the build output to /dev/null was actually rather effective, it shaved about 5 minutes from the build time. This isn’t a great solution though as I’d like to see progress and warnings. Another suggestion was to disable parts of Firefox that I don’t need, unfortunately I often tinker with files that are used throughout the codebase so I can’t disable things without worrying about breaking them.

Any other suggestions out there? Links to bugs?