| OLD | NEW |
| (Empty) |
| 1 # Tips for improving build speed on Linux | |
| 2 | |
| 3 This list is sorted such that the largest speedup is first; see | |
| 4 [Linux build instructions](linux_build_instructions.md) for context and | |
| 5 [Faster Builds](common_build_tasks.md) for non-Linux-specific techniques. | |
| 6 | |
| 7 [TOC] | |
| 8 | |
| 9 ## General configuration | |
| 10 | |
| 11 The [GN build configuration](https://www.chromium.org/developers/gn-build-config
uration) | |
| 12 page discusses a number of options that will speed up your build. In particular: | |
| 13 | |
| 14 is_component_build = true | |
| 15 enable_nacl = false | |
| 16 symbol_level = 0 | |
| 17 remove_webcore_debug_symbols = true | |
| 18 | |
| 19 ## Use goma | |
| 20 | |
| 21 If you work at Google, you can use goma for distributed builds; this is similar | |
| 22 to [distcc](http://en.wikipedia.org/wiki/Distcc). See [go/ma](http://go/ma) for | |
| 23 documentation. | |
| 24 | |
| 25 Even without goma, you can do distributed builds with distcc (if you have access | |
| 26 to other machines), or a parallel build locally if have multiple cores. | |
| 27 | |
| 28 Whether using goma, distcc, or parallel building, you can specify the number of | |
| 29 build processes with `-jX` where `X` is the number of processes to start. | |
| 30 | |
| 31 ## Use Icecc | |
| 32 | |
| 33 [Icecc](https://github.com/icecc/icecream) is the distributed compiler with a | |
| 34 central scheduler to share build load. Currently, many external contributors use | |
| 35 it. e.g. Intel, Opera, Samsung. | |
| 36 | |
| 37 When you use Icecc, you need to [set some GN variables](https://www.chromium.org
/developers/gn-build-configuration). | |
| 38 | |
| 39 linux_use_bundled_binutils = false | |
| 40 | |
| 41 The `-B` option is not supported. | |
| 42 [relevant commit](https://github.com/icecc/icecream/commit/b2ce5b9cc4bd1900f55c3
684214e409fa81e7a92) | |
| 43 | |
| 44 use_debug_fission = false | |
| 45 | |
| 46 [debug fission](http://gcc.gnu.org/wiki/DebugFission) is not supported. | |
| 47 [bug](https://github.com/icecc/icecream/issues/86) | |
| 48 | |
| 49 is_clang = false | |
| 50 | |
| 51 Icecc doesn't support clang yet. | |
| 52 | |
| 53 use_sysroot = false | |
| 54 | |
| 55 Icecc doesn't work with sysroot. | |
| 56 | |
| 57 Using the system linker is necessary when using glibc 2.21 or newer. See | |
| 58 [related bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808181). | |
| 59 Previously these instructions listed the linux_use_bundled_gold GYP variable | |
| 60 which no longer exists. If you know about this, please update or delete this | |
| 61 section. | |
| 62 | |
| 63 ## WebKit | |
| 64 | |
| 65 ### Build WebKit without debug symbols | |
| 66 | |
| 67 WebKit is about half our weight in terms of debug symbols. (Lots of templates!) | |
| 68 If you're working on UI bits where you don't care to trace into WebKit you can | |
| 69 cut down the size and slowness of debug builds significantly by building WebKit | |
| 70 without debug symbols. | |
| 71 | |
| 72 Set the GN build arg `remove_webcore_debug_symbols=true` (to edit build args | |
| 73 run `gn args out/foo` where `out/foo` is your build directory). | |
| 74 | |
| 75 ## Tune ccache for multiple working directories | |
| 76 | |
| 77 (Ignore this if you use goma.) | |
| 78 | |
| 79 Increase your ccache hit rate by setting `CCACHE_BASEDIR` to a parent directory | |
| 80 that the working directories all have in common (e.g., | |
| 81 `/home/yourusername/development`). Consider using | |
| 82 `CCACHE_SLOPPINESS=include_file_mtime` (since if you are using multiple working | |
| 83 directories, header times in svn sync'ed portions of your trees will be | |
| 84 different - see | |
| 85 [the ccache troubleshooting section](http://ccache.samba.org/manual.html#_troubl
eshooting) | |
| 86 for additional information). If you use symbolic links from your home directory | |
| 87 to get to the local physical disk directory where you keep those working | |
| 88 development directories, consider putting | |
| 89 | |
| 90 alias cd="cd -P" | |
| 91 | |
| 92 in your `.bashrc` so that `$PWD` or `cwd` always refers to a physical, not | |
| 93 logical directory (and make sure `CCACHE_BASEDIR` also refers to a physical | |
| 94 parent). | |
| 95 | |
| 96 If you tune ccache correctly, a second working directory that uses a branch | |
| 97 tracking trunk and is up to date with trunk and was gclient sync'ed at about the | |
| 98 same time should build chrome in about 1/3 the time, and the cache misses as | |
| 99 reported by `ccache -s` should barely increase. | |
| 100 | |
| 101 This is especially useful if you use `git-new-workdir` and keep multiple local | |
| 102 working directories going at once. | |
| 103 | |
| 104 ## Using tmpfs | |
| 105 | |
| 106 You can use tmpfs for the build output to reduce the amount of disk writes | |
| 107 required. I.e. mount tmpfs to the output directory where the build output goes: | |
| 108 | |
| 109 As root: | |
| 110 | |
| 111 mount -t tmpfs -o size=20G,nr_inodes=40k,mode=1777 tmpfs /path/to/out | |
| 112 | |
| 113 *** note | |
| 114 **Caveat:** You need to have enough RAM + swap to back the tmpfs. For a full | |
| 115 debug build, you will need about 20 GB. Less for just building the chrome target | |
| 116 or for a release build. | |
| 117 *** | |
| 118 | |
| 119 Quick and dirty benchmark numbers on a HP Z600 (Intel core i7, 16 cores | |
| 120 hyperthreaded, 12 GB RAM) | |
| 121 | |
| 122 * With tmpfs: | |
| 123 * 12m:20s | |
| 124 * Without tmpfs | |
| 125 * 15m:40s | |
| OLD | NEW |