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 |