slow.rst (6938B)
1 .. _slow: 2 3 ================================== 4 Why the Build System might be slow 5 ================================== 6 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. 10 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 13 be different. 14 15 The build does a lot of work 16 ============================ 17 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. 23 24 You don't have enough CPU cores and MHz 25 ======================================= 26 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. 32 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. 37 38 This cause impacts both clobber and incremental builds. 39 40 You are building with a slow I/O layer 41 ====================================== 42 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 45 of I/O. 46 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 50 possible. 51 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 65 faster. 66 67 This cause impacts both clobber and incremental builds. 68 69 You don't have enough memory 70 ============================ 71 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 78 the build system. 79 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. 84 85 This cause impacts both clobber and incremental builds. 86 87 You are building on Windows 88 =========================== 89 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. 99 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. 106 107 These issues impact both clobber and incremental builds. 108 109 make is inefficient 110 =================== 111 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 115 faster. 116 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 119 system. 120 121 C++ header dependency hell 122 ========================== 123 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. 127 128 Our code base has traditionally been sloppy managing the impact of 129 changed headers on build performance. Bug 785103 tracks improving the 130 situation. 131 132 This issue mostly impacts the times of an :term:`incremental build`. 133 134 A search/indexing service on your machine is running 135 ==================================================== 136 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. 140 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. 146 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 153 how to fix it.