3 ==================================
4 Why the Build System might be slow
5 ==================================
7 A common complaint about the build system is that it can be slow. There are
8 many reasons contributing to its slowness.
9 However, on modern hardware, Firefox can be built in less than 10 minutes.
11 First, it is important to distinguish between a :term:`clobber build`
12 and an :term:`incremental build`. The reasons for why each are slow can
15 The build does a lot of work
16 ============================
18 It may not be obvious, but the main reason the build system is slow is
19 because it does a lot of work! The source tree consists of a few
20 thousand C++ files. On a modern machine, we spend over 120 minutes of CPU
21 core time compiling files! So, if you are looking for the root cause of
22 slow clobber builds, look at the sheer volume of C++ files in the tree.
24 You don't have enough CPU cores and MHz
25 =======================================
27 The build should be CPU bound. If the build system maintainers are
28 optimizing the build system perfectly, every CPU core in your machine
29 should be 100% saturated during a build. While this isn't currently the
30 case (keep reading below), generally speaking, the more CPU cores you
31 have in your machine and the more total MHz in your machine, the better.
33 **We highly recommend building with no fewer than 4 physical CPU
34 cores.** Please note the *physical* in this sentence. Hyperthreaded
35 cores (an Intel Core i7 will report 8 CPU cores but only 4 are physical
36 for example) only yield at most a 1.25x speedup per core.
38 This cause impacts both clobber and incremental builds.
40 You are building with a slow I/O layer
41 ======================================
43 The build system can be I/O bound if your I/O layer is slow. Linking
44 libxul on some platforms and build architectures can perform gigabytes
47 To minimize the impact of slow I/O on build performance, **we highly
48 recommend building with an SSD.** Power users with enough memory may opt
49 to build from a RAM disk. Mechanical disks should be avoided if at all
52 Some may dispute the importance of an SSD on build times. It is true
53 that the beneficial impact of an SSD can be mitigated if your system has
54 lots of memory and the build files stay in the page cache. However,
55 operating system memory management is complicated. You don't really have
56 control over what or when something is evicted from the page cache.
57 Therefore, unless your machine is a dedicated build machine or you have
58 more memory than is needed by everything running on your machine,
59 chances are you'll run into page cache eviction and you I/O layer will
60 impact build performance. That being said, an SSD certainly doesn't
61 hurt build times. And, anyone who has used a machine with an SSD will
62 tell you how great of an investment it is for performance all around the
63 operating system. On top of that, some automated tests are I/O bound
64 (like those touching SQLite databases), so an SSD will make tests
67 This cause impacts both clobber and incremental builds.
69 You don't have enough memory
70 ============================
72 The build system allocates a lot of memory, especially when building
73 many things in parallel. If you don't have enough free system memory,
74 the build will cause swap activity, slowing down your system and the
75 build. Even if you never get to the point of swapping, the build system
76 performs a lot of I/O and having all accessed files in memory and the
77 page cache can significantly reduce the influence of the I/O layer on
80 **We recommend building with no less than 8 GB of system memory.** As
81 always, the more memory you have, the better. For a bare bones machine
82 doing nothing more than building the source tree, anything more than 16
83 GB is likely entering the point of diminishing returns.
85 This cause impacts both clobber and incremental builds.
87 You are building on Windows
88 ===========================
90 New processes on Windows are about a magnitude slower to spawn than on
91 UNIX-y systems such as Linux. This is because Windows has optimized new
92 threads while the \*NIX platforms typically optimize new processes.
93 Anyway, the build system spawns thousands of new processes during a
94 build. Parts of the build that rely on rapid spawning of new processes
95 are slow on Windows as a result. This is most pronounced when running
96 *configure*. The configure file is a giant shell script and shell
97 scripts rely heavily on new processes. This is why configure
98 can run over a minute slower on Windows.
100 Another reason Windows builds are slower is because Windows lacks proper
101 symlink support. On systems that support symlinks, we can generate a
102 file into a staging area then symlink it into the final directory very
103 quickly. On Windows, we have to perform a full file copy. This incurs
104 much more I/O. And if done poorly, can muck with file modification
105 times, messing up build dependencies.
107 These issues impact both clobber and incremental builds.
112 Compared to modern build backends like Tup or Ninja, `make` is slow and
113 inefficient. We can only make `make` so fast. At some point, we'll hit a
114 performance plateau and will need to use a different tool to make builds
117 Please note that clobber and incremental builds are different. A clobber build
118 with `make` will likely be as fast as a clobber build with a modern build
121 C++ header dependency hell
122 ==========================
124 Modifying a *.h* file can have significant impact on the build system.
125 If you modify a *.h* that is used by 1000 C++ files, all of those 1000
126 C++ files will be recompiled.
128 Our code base has traditionally been sloppy managing the impact of
129 changed headers on build performance. Bug 785103 tracks improving the
132 This issue mostly impacts the times of an :term:`incremental build`.
134 A search/indexing service on your machine is running
135 ====================================================
137 Many operating systems have a background service that automatically
138 indexes filesystem content to make searching faster. On Windows, you
139 have the Windows Search Service. On OS X, you have Finder.
141 These background services sometimes take a keen interest in the files
142 being produced as part of the build. Since the build system produces
143 hundreds of megabytes or even a few gigabytes of file data, you can
144 imagine how much work this is to index! If this work is being performed
145 while the build is running, your build will be slower.
147 OS X's Finder is notorious for indexing when the build is running. And,
148 it has a tendency to suck up a whole CPU core. This can make builds
149 several minutes slower. If you build with ``mach`` and have the optional
150 ``psutil`` package built (it requires Python development headers - see
151 :ref:`python` for more) and Finder is running during a build, mach will
152 print a warning at the end of the build, complete with instructions on