|
LinuxFasterBuilds
tips for improving build speed on Linux
This list is sorted such that the largest speed up is first. Build only specific targetsIf 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 You can also specify explicit files that you want built. The above is basically equivalent to: $ cd $CHROMIUM_ROOT/src $ make out/Debug/base_unittests Linking using goldThe experimental "gold" linker is much faster than the standard one. On some systems (including Debian experimental, Ubuntu Karmic), just apt-get install binutils-gold. Otherwise, try running src/build/install-build-deps.sh and answer Y when it asks you if you want to use gold as your system linker. If you want to do it the hard way, here are the old instructions:
Build WebKit without debug symbolsWebKit 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,
},
}Shared librariesWe normally static link, which produces enormous (test_shell has been seen at nearly 500mb) executables. 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 -Dlibrary=shared_library flag to put it in this configuration. Note that this build frequently breaks, so if it doesn't work it's up to you to diagnose. Using tmpfsIf you have RAM to spare, 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:
Caveat: Make sure you have enough ram to do this, otherwise your system will thrash. In particular, if you have a 4G of ram on your machine, don't set this to 4G, or probably even 3G. You need enough space to keep running your linkers, compilers, desktop, browsers, editors, etc. Scons TricksAvoid Scons entirelyFollow the normal LinuxBuildInstructions. If you really want to keep using Scons, keep reading. Loading only part of the build configurationYou can tell our scons scripts to only load the dependency info for certain targets. For example, if you're working on files in base/ and only building the tests there, you can pass LOAD=base,base_unittests on the command line to only load the base .scons files necessary for building the base library and its unittests. Note that if you edit a file outside of the SConscript set you're loading, SCons won't pick up that the file has changed. $ cd $CHROMIUM_ROOT/src/build $ hammer LOAD=webkit If you're primarily focusing on the browser, then use the following command line: $ cd $CHROMIUM_ROOT/src/build $ hammer --implicit-cache chrome LOAD=chrome,browser This dropped the time it takes scons to figure out nothing changed from 36 seconds to 6 seconds on my machine. NOTE: the targets defined by gyp are now more fine-grained than the old "Hammer" targets, and don't necessarily pull in all of the dependent configurations. So if you now specify (e.g.) LOAD=base_unittests, that only loads the configuration necessary to build the actual base_unittests executable, and does not load the dependency information for building libbase.a--that is, it would treat libbase.a as a "source file" input to the link of base_unittests. SCons interactive modeSCons loads its SConscript files each time you run it. If you instead leave it running between builds, it doesn't need to reload the files. Pass the --interactive flag on your command line (ideally with LOAD= flags too) and then from the SCons prompt build with a command like b test_shell. $ cd $CHROMIUM_ROOT/src/build $ hammer --interactive scons>>>b test_shell Note that you'll need to restart hammer if you edit a .gyp file, or if you want to change the portion of the configuration you load with LOAD=. |