Andrew Kelley 曾有句名言（或是惡名昭彰的話，取決於你的看法）：「編譯器他媽的太慢了，這就是我們會有 bug 的原因。」¹

因此，多年來 Zig 明確宣示的主要目標之一，就是更快的編譯時間。Zig 團隊為了實現這個目標，一直在處理極其困難的問題（例如汰除 LLVM、撰寫自己的程式碼產生後端、打造自己的連結器，以及整體朝增量編譯邁進）。²

這項多年耕耘的成果，終於在 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

這是在對最核心的終端機模擬程式碼進行一行修改後（在跳脫序列解析器中加入一個 log 函式呼叫），重新建置 Ghostty 所需的時間。

這次建置的建置腳本與相依圖都已完全快取，所以只會重新建置必要的部分。Zig 的增量編譯功能目前尚未可用，因此仍會重新編譯相當多的程式碼。此外，如同前一節所述，這仍在使用 LLVM。光是把 LLVM 拿掉，我預期這個時間就會降到大約 12 秒左右（扣除 LLVM 產生程式碼的時間）。

再往前看，一旦 Zig 支援增量編譯，我預期像這樣的增量建置最慢也只需數毫秒就能完成。不過，就等到成真時再來驗證吧。

增量建置（libghostty-vt）

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

這是僅重新建置 libghostty-vt 在一行修改後所需的時間。與 Ghostty 執行檔不同，libghostty-vt 已能完全在自託管的 x86_64 後端上正常運作，因此這呈現了在沒有 LLVM 參與的情況下，建置時間的差異。

與 Ghostty 執行檔類似，由於增量編譯尚未完全可用，這仍會重新建置 libghostty-vt 的整個 Zig 模組。我預期一旦增量編譯成真，這個時間最慢也會降至個位數的毫秒。

但即便如此，一個非同小可的函式庫能在不到一秒內完成建置，已經是令人驚艷了。這正是我目前花最多時間開發的函式庫，而自從升級到 Zig 0.15.1 後的短短幾天內，我就已經感受到工作流程上的巨大差異。以前，我可能會在建置或測試的空檔切換視窗去看個電子郵件，但現在速度快到讓我可以一直待在終端機裡保持專注。

這項改進最能預示短期內的發展。 自託管的 x86_64 後端已經穩定到足以預設建置所有的 debug 版本，而 aarch64 後端也正迎頭趕上。我們目前還無法建置完整的 Ghostty 執行檔，但我敢說這個問題在幾個月內就會解決。

更快的建置已經到來

如你所見，使用 Zig 0.15.1 建置 Ghostty 在每一種情境下都更快，儘管 Ghostty 有很大一部分甚至還無法利用自託管後端！而且儘管增量編譯還未能運作！

我很高興當初選擇押注 Zig 來打造 Ghostty，也很樂見他們專注於編譯時間。這些改進是真實的，而且現在就已經實現了。而我懷疑，再過個一兩年，今天發布的這些數據看起來就會慢得不可思議。😜