Andrew Kelley（安德鲁·凯利）曾有一句名言（或者说臭名昭著的话，取决于你的观点）：“编译器他妈的太慢了，所以我们才会有 bug。”¹

因此，多年来，更快的编译时间一直是 Zig 的主要公开目标之一。Zig 团队一直在攻克极其困难的难题以实现这一目标（例如 抛弃 LLVM、编写自己的 code generation backends(代码生成后端)、构建自己的 链接器，以及总体上朝着 incremental compilation(增量编译) 迈进）。²

这项历时数年的努力成果终于在 Zig 0.15.1 中开始显现。Ghostty 项目刚刚完成了向 Zig 0.15.1 的升级，我想分享一些真实世界的构建时间。³

构建脚本编译

• Zig 0.14: 7sec 167ms
• Zig 0.15: 1sec 702ms

这是构建 build.zig 脚本本身所需的时间。上述时间是通过运行 zig build --help 测得的。

一个编写良好的构建脚本应该很少需要重新构建自身。然而，这是每一次全新的未缓存源码构建都必须付出的成本（例如，用户下载项目后首次从源码构建）。因此，它直接影响到构建出可用二进制文件所需的时间。

完整未缓存的 Ghostty 二进制文件

• Zig 0.14: 41sec
• Zig 0.15: 32sec

这其中包含了构建脚本本身的时间。结合前面的结果，Zig 0.15 构建其余部分的速度快了约 2 秒。但是，你仍然可以在总耗时（wall time）上看到这次初始构建时间的变化。

重要提示：其中大部分仍然在使用 LLVM。 Ghostty 仍然无法完全使用自托管的 x86_64 后端进行构建和链接，因为该后端仍有 bug。因此，这仅仅展示了 Zig 编译器本身的整体改进，即使在仍使用 LLVM 的情况下。

一旦 Ghostty 能够完全使用自托管的 x86_64 后端，我预计这个时间会骤降至 25 秒左右甚至更少，仅为使用 Zig 0.14 所需时间的一半。

增量构建（Ghostty 可执行文件）

• Zig 0.14: 19sec
• Zig 0.15: 16sec

这是在对最核心的终端仿真代码进行一行修改后（在转义序列解析器中添加一个日志函数调用）重新构建 Ghostty 所需的时间。

此次构建的构建脚本和依赖图已完全缓存，因此只会重新构建必要的部分。Zig 中的 incremental compilation 尚未可用，因此仍会重新编译相当数量的代码。此外，与上一节一样，这仍然在使用 LLVM。仅仅是将 LLVM 排除在外，我预计这个时间就会降至 12 秒左右（减去 LLVM 生成代码所花费的时间）。

更进一步，一旦 Zig 支持 incremental compilation，我预计像这样的增量构建最慢也能在毫秒级内完成。但是，让我们拭目以待，看看那何时成为现实。

增量构建（libghostty-vt）

• Zig 0.14: 2sec 884ms
• Zig 0.15: 975ms

这是仅对 libghostty-vt 进行一行修改后重新构建所需的时间。与 Ghostty 可执行文件不同，libghostty-vt 已可在自托管的 x86_64 后端上完全正常工作，因此这展示了在没有 LLVM 情况下构建时间的差异。

与 Ghostty 可执行文件类似，由于 incremental compilation 尚未完全可用，这仍然会重新构建 libghostty-vt 的整个 Zig 模块。我预计一旦 incremental compilation 成为现实，这个时间最慢也会降至个位数毫秒。

但即便如此，一个非平凡库的亚秒级构建时间已经令人惊叹。这是我目前花费最多时间开发的库，即使在升级到 Zig 0.15.1 后的短短几天里，我就已经感受到了工作流程的巨大差异。以前，我可能会在构建或测试的间隙切换窗口去读邮件，但现在它的速度如此之快，以至于我可以一直在终端中保持专注的工作流。

这一改进最能说明短期内的发展趋势。 自托管的 x86_64 后端已经足够稳定，可以默认构建所有 debug 构建，而 aarch64 后端也在接近这一目标。我们目前还无法构建完整的 Ghostty 可执行文件，但我敢打赌这个问题会在几个月内得到解决。

更快的构建已然到来

如你所见，使用 Zig 0.15.1 构建 Ghostty 在每一种场景下都更快，尽管 Ghostty 的很大一部分甚至还无法利用自托管后端！而且尽管 incremental compilation 尚未可用！

我很庆幸为 Ghostty 选择押注 Zig，也很高兴他们专注于编译时间。这些改进是实实在在的，而且现在就已经实现。我猜想在未来一两年内，今天发布的结果看起来都会显得相当缓慢。😜