构建系统可能变慢的原因¶
关于构建系统的一个常见抱怨是它可能很慢。有很多原因导致它变慢。但是，在现代硬件上，Firefox 的构建时间可以短于 10 分钟。
首先，区分彻底构建和增量构建很重要。每个构建变慢的原因可能不同。
构建做了很多工作¶
可能不明显，但构建系统变慢的主要原因是它做了很多工作！源代码树包含几千个 C++ 文件。在现代机器上，我们花费超过 120 分钟的 CPU 核心时间来编译文件！因此，如果您正在寻找彻底构建变慢的根本原因，请查看树中大量的 C++ 文件。
您的 CPU 核心和 MHz 不足¶
构建应该受 CPU 限制。如果构建系统维护人员完美地优化了构建系统，则在构建期间，您机器中的每个 CPU 核心都应该达到 100% 的饱和状态。虽然目前情况并非如此（请继续阅读下面的内容），但一般来说，您的机器上拥有的 CPU 核心越多，机器上的总 MHz 越高，效果越好。
我们强烈建议使用不少于 4 个物理 CPU 核心进行构建。请注意这句话中的“物理”。超线程核心（例如，英特尔酷睿 i7 将报告 8 个 CPU 核心，但只有 4 个是物理核心）每个核心最多只能提高 1.25 倍的速度。
此原因会影响彻底构建和增量构建。
您使用的是缓慢的 I/O 层进行构建¶
如果您的 I/O 层速度缓慢，则构建系统可能会受 I/O 限制。在某些平台和构建架构上链接 libxul 可能会执行千兆字节的 I/O。
为了最大程度地减少缓慢的 I/O 对构建性能的影响，我们强烈建议使用 SSD 进行构建。拥有足够内存的高级用户可以选择从 RAM 磁盘构建。应尽可能避免使用机械磁盘。
有些人可能会对 SSD 对构建时间的重要性提出异议。确实，如果您的系统拥有大量内存并且构建文件保留在页面缓存中，则 SSD 的有利影响可能会减弱。但是，操作系统内存管理非常复杂。您实际上无法控制何时以及从页面缓存中逐出什么内容。因此，除非您的机器是专用的构建机器，或者您的内存比机器上所有正在运行的程序所需的内存都多，否则您很可能会遇到页面缓存逐出，并且您的 I/O 层将影响构建性能。也就是说，SSD 当然不会损害构建时间。而且，任何使用过装有 SSD 的机器的人都将告诉您，对于整个操作系统的性能来说，这是一项多么好的投资。最重要的是，一些自动化测试受 I/O 限制（例如那些访问 SQLite 数据库的测试），因此 SSD 会使测试更快。
此原因会影响彻底构建和增量构建。
您的内存不足¶
构建系统会分配大量内存，尤其是在并行构建许多内容时。如果您的可用系统内存不足，构建将导致交换活动，从而降低系统和构建的速度。即使您从未达到交换的程度，构建系统也会执行大量的 I/O，并且将所有访问的文件都保存在内存和页面缓存中可以显着减少 I/O 层对构建系统的影响。
我们建议使用不少于 8 GB 的系统内存进行构建。与往常一样，内存越多越好。对于一台仅用于构建源代码树的简单机器，超过 16 GB 的内存很可能会进入收益递减的阶段。
此原因会影响彻底构建和增量构建。
您在 Windows 上构建¶
Windows 上的新进程比 Linux 等类 Unix 系统上的新进程慢大约一个数量级。这是因为 Windows 优化了新线程，而 *NIX 平台通常优化了新进程。无论如何，构建系统在构建期间会生成数千个新进程。因此，依赖于快速生成新进程的构建部分在 Windows 上速度很慢。这在运行配置时最为明显。配置文件是一个巨大的 shell 脚本，而 shell 脚本严重依赖于新进程。这就是为什么配置在 Windows 上可能运行速度慢超过一分钟的原因。
Windows 构建速度较慢的另一个原因是 Windows 缺少适当的符号链接支持。在支持符号链接的系统上，我们可以非常快地将文件生成到暂存区，然后将其符号链接到最终目录中。在 Windows 上，我们必须执行完整的文件复制。这会产生更多的 I/O。如果操作不当，可能会弄乱文件修改时间，从而弄乱构建依赖项。
这些问题会影响彻底构建和增量构建。
make 效率低下¶
与 Tup 或 Ninja 等现代构建后端相比，make 速度慢且效率低下。我们只能使 make 变得如此快。在某些时候，我们将达到性能平台，并将需要使用其他工具来加快构建速度。
请注意，彻底构建和增量构建是不同的。make 的彻底构建速度可能与现代构建系统的彻底构建一样快。
C++ 头文件依赖关系地狱¶
修改.h文件可能会对构建系统产生重大影响。如果您修改了 1000 个 C++ 文件使用的.h文件，则所有这 1000 个 C++ 文件都将重新编译。
我们的代码库在管理更改的头文件对构建性能的影响方面历来比较粗心。Bug 785103 跟踪改进这种情况。
此问题主要影响增量构建的时间。
您的机器上正在运行搜索/索引服务¶
许多操作系统都有一个后台服务，可以自动索引文件系统内容以加快搜索速度。在 Windows 上，您有 Windows 搜索服务。在 OS X 上，您有 Finder。
这些后台服务有时会对作为构建的一部分而生成的文件产生浓厚的兴趣。由于构建系统会生成数百兆字节甚至几千兆字节的文件数据，因此您可以想象索引这些文件需要多少工作！如果这项工作是在构建过程中执行的，则您的构建速度会变慢。
OS X 的 Finder 以在构建过程中进行索引而闻名。而且，它有占用整个 CPU 核心的趋势。这会使构建速度慢几分钟。如果您使用 mach 进行构建并且构建了可选的 psutil 包（它需要 Python 开发头文件 - 有关详细信息，请参阅Python 和构建系统），并且在构建期间 Finder 正在运行，则 mach 将在构建结束时打印警告，并附带有关如何修复它的说明。