build/docs/slow.rst

   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.