Zig Build System Rework: 90% Faster, Ships in 0.17

Andrew Kelley merged a 30,000-line PR into Zig’s main branch on May 26 that reworks the Zig build system at the architecture level. The headline number: zig build --help drops from 150ms wall time to 14.3ms — a 90% improvement — with 95.9% fewer CPU cycles. This is not micro-optimization. It is a structural change that affects every invocation of the build system, and it ships in Zig 0.17.0, which Kelley says is weeks away.

What Changed: Two Processes Instead of One

Previously, build.zig (the user’s build configuration script) and the Zig build system itself were compiled into a single process. Every call to zig build triggered a recompile of this combined binary, regardless of whether anything had changed. The new design, detailed in the official Zig 2026 devlog, splits this into two distinct processes.

The configurer compiles build.zig in debug mode, constructs the build graph in memory, and serializes it to a binary configuration file. The parent zig build process caches this file. The maker — compiled in release mode with full optimizations — reads the serialized config and executes the build graph. The maker is cached globally, not per-project. When inputs have not changed, the configurer does not run at all.

This mirrors how tools like Meson separate configure and build phases conceptually, but now Zig enforces it at the process boundary. The maker runs optimized code. The configurer only recompiles when it needs to. Moreover, the build system can grow more features — --watch, --fuzz, --webui — without those features adding to the baseline cost of every zig build invocation.

Zig Build Performance: The Numbers Are Real

Kelley published benchmarks in the Zig devlog on May 26. For zig build -h, the numbers are: wall time goes from 150ms ± 5.52ms on master to 14.3ms ± 744us on the new branch. CPU cycles drop 95.9%. Memory usage falls 7.4%. You do not often see two-order-of-magnitude improvements from a tooling change — these gains come entirely from architecture, not algorithmic tricks.

For workflows that repeatedly invoke the build system — CI pipelines, --watch mode, fuzzing runs — this compounds significantly. The Hacker News discussion (311 points as of this writing) reflects genuine enthusiasm from developers who have felt this friction firsthand. One top commenter described the changes as setting “the language for a bright future.”

What Breaks and How to Fix It

Kelley’s devlog describes the rework as “mostly non-breaking from an API perspective,” but there is one meaningful exception: code that inspects b.args to pass CLI arguments to run commands no longer works. The configure phase is now a separate process without direct access to the parent’s arguments. The fix is straightforward:

// Old pattern (broken in 0.17)
if (b.args) |args| {
    run_cmd.addArgs(args);
}

// New pattern (required in 0.17)
run_cmd.addPassthruArgs();

Arguments now pass through at execution time rather than being observed from within the configure phase. This is architecturally cleaner — it reflects the actual process model. However, it is a real migration step for any build.zig that forwards arguments to run commands, which is common in projects using zig build run -- --my-flag patterns.

The community frustration is documented and fair. One developer on HN put it directly: “I have some zig projects from a couple months back… the API changed and that is broken now.” This is the pre-1.0 reality with Zig. The core team is making long-term correctness decisions, and that means shorter-term compatibility pain. Reasonable people disagree about whether that tradeoff is worth it — but the architectural direction here is sound.

Related: Rust 1.96.0: Copyable Ranges, assert_matches, and Two Cargo CVEs

What Else Benefits: ZLS and Zig 0.17 Timeline

One underreported benefit: ZLS (Zig Language Server), which powers IDE autocomplete and go-to-definition, currently maintains a fork of the build runner to extract build configuration. With the new serialized binary config, ZLS can read that file directly. This reduces ZLS maintenance burden and should improve the accuracy and speed of build-system-aware IDE features — a real quality-of-life improvement for anyone doing Zig development in VS Code or Neovim.

The rework lands in Zig 0.17.0, which Kelley indicated is weeks away as of late May. Unlike Zig 0.16 — which took over a year and covered a massive compiler refactor — 0.17 is relatively contained: the build system rework plus an LLVM 22 upgrade. That is why the release cadence is accelerating. If you are on Zig today, migration is mostly a single function call change. If you are evaluating Zig for a systems project, this is the build tooling maturity signal worth watching.

Key Takeaways

• The Zig build system now separates configuration (debug mode, cached) from execution (release mode, optimized), cutting zig build wall time 90% and CPU cycles 95.9%
• The primary migration: replace b.args argument forwarding with run_cmd.addPassthruArgs() — a one-line change for most projects
• ZLS benefits directly: the serialized config file eliminates the need for the language server to fork the build runner, improving IDE integration
• Zig 0.17.0 ships this change; expect it in June 2026 with a faster-than-usual release cadence due to the contained scope
• API churn is real and documented — an acknowledged pre-1.0 tradeoff the Zig team is making deliberately