This list is sorted such that the largest speed up is first.

• Use ninja
• Build only specific targets
• Shared libraries (components)
• Linking using gold
• Build WebKit without debug symbols
• Build WebKit without SVG support
• Tell Make to load fewer dependencies (NO_LOAD)
• Tune ccache for multiple working directories
• Using tmpfs

Use ninja

See NinjaBuild.

Build only specific targets

If you specify just the target(s) you want built, the build will only walk that portion of the dependency graph:

$ cd $CHROMIUM_ROOT/src
$ make base_unittests

Shared libraries (components)

We normally statically link everything into one final executable, which produces enormous (nearly 1gb in debug mode) files. If you dynamically link, you save a lot of time linking for a bit of time during startup, which is fine especially when you're in an edit/compile/test cycle.

Run gyp with the -Dcomponent=shared_library flag to put it in this configuration. (Or set those flags via the GYP_DEFINES environment variable.)

e.g.

$ export LD_LIBRARY_PATH=/path/to/out/Debug/lib.target
$ ./build/gyp_chromium -D component=shared_library -D disable_nacl=1
$ make out/Debug/chrome -j6

See http://crbug.com/84924 for why you may need to disable nacl.

Warning: this build configuration is still experimental, and it disables parts of Chrome. Please only use it for development and not for any release to users.

Linking using gold

The experimental "gold" linker is much faster than the standard BFD linker.

On some systems (including Debian experimental, Ubuntu Karmic and beyond), there exists a binutils-gold package. Do not install this version! Having gold as the default linker is known to break kernel / kernel module builds.

The Chrome tree now includes a binary of gold compiled for x64 Linux. It is used by default on those systems.

On other systems, to safely install gold, make sure the final binary is named ld and then set CC/CXX appropriately, e.g. export CC="gcc -B/usr/local/gold/bin" and similarly for CXX. Alternatively, you can add /usr/local/gold/bin to your PATH in front of /usr/bin.

Build WebKit without debug symbols

WebKit is about half our weight in terms of debug symbols. (Lots of templates!) If you're working on UI bits where you don't care to trace into WebKit you can cut down the size and slowness of debug builds significantly by building WebKit without debug symbols.

Set the gyp variable remove_webcore_debug_symbols=1, either via the GYP_DEFINES environment variable, the -D flag to gyp, or by adding the following to ~/.gyp/include.gypi:

{
  'variables': {
    'remove_webcore_debug_symbols': 1,
  },
}

Build WebKit without SVG support

The WebKit SVG code takes a long time to compile. (Again, lots of templates) If you don't expect to use SVG, then you can get another boost by removing SVG support. Set the gyp variable enable_svg=0.

Tell Make to load fewer dependencies (NO_LOAD)

Here's an example:

make -j16 net_unittests NO_LOAD="chrome webkit third views" 

What this does is cause make not to load any .mk file that is in chrome, webkit, third_party or views. net_unittests doesn't need those files, so you're normally stat'ing thousands of files unnecessarily.

You can also use this for incremental builds. For example:

make -j 16 chrome NO_LOAD="webkit third" 

Since this doesn't load any of WebKit/WebCore, you should see incremental builds be a few seconds faster (assuming libWebKit.a, libwebcore_remaining.a, etc are up to date).

NO_LOAD just checks to see if the prefix matches, so you could abbreviate with NO_LOAD="w t".

Tune ccache for multiple working directories

Increase your ccache hit rate by setting CCACHE_BASEDIR to a parent directory that the working directories all have in common (e.g., /home/yourusername/development). Consider using CCACHE_SLOPPINESS=include_file_mtime (since if you are using multiple working directories, header times in svn sync'ed portions of your trees will be different - see the ccache troubleshooting section for additional information). If you use symbolic links from your home directory to get to the local physical disk directory where you keep those working development directories, consider putting

alias cd="cd -P"

in your .bashrc so that $PWD or cwd always refers to a physical, not logical directory (and make sure CCACHE_BASEDIR also refers to a physical parent).

If you tune ccache correctly, a second working directory that uses a branch tracking trunk and is up-to-date with trunk and was gclient sync'ed at about the same time should build chrome in about 1/3 the time, and the cache misses as reported by ccache -s should barely increase.

This is especially useful if you use git-new-workdir and keep multiple local working directories going at once.

Using tmpfs

You can use tmpfs for the build output to reduce the amount of disk writes required. I.e. mount tmpfs to the output directory where the build output goes:

As root:

• mount -t tmpfs -o size=20G,nr_inodes=40k,mode=1777 tmpfs /path/to/out

Caveat: You need to have enough RAM + swap to back the tmpfs. For a full debug build, you will need about 20 GB. Less for just building the chrome target or for a release build.

Quick and dirty benchmark numbers on a HP Z600 (Intel core i7, 16 cores hyperthreaded, 12 GB RAM)