Zig's Incremental Compilation: 50ms Rebuilds From a Core Team Deep Dive

Last updated: July 29, 2026

Zig's incremental compilation has been years in the making -- the feature was first proposed in issue #1535, and over recent release cycles it has evolved from a proof-of-concept to something the core team uses daily. Now Zig core team member mlugg has published the most thorough walkthrough yet of how it actually works: the file-processing pipeline, the four kinds of semantic analysis units, the dependency graph that tracks what changed, and the custom incremental linker that patches bytes directly into the output binary.

The post hit the Hacker News front page on July 28 and collected 244 points and 172 comments. The discussion attracted some of the most respected voices in systems programming, including Rust core team member steveklabnik and a rust-analyzer maintainer, making this one of the more substantive compiler-engineering threads in recent memory.

What the Article Says#

The post covers the full Zig compiler pipeline, from source file to linked binary, explaining how each stage handles incremental updates.

File processing is the first stage: parse source files into an AST, then convert to ZIR (Zig Intermediate Representation). This stage is a pure function of each file's contents, is embarrassingly parallel, and has been cached on disk for years. It already runs near-instantly on most rebuilds.

Semantic analysis is where the hard work lives. The compiler splits compilation into four kinds of analysis units: the layout of a struct or union type, the type of a container-level declaration, the value of a const declaration, and the body of a runtime function. Each unit tracks what it depends on, building a dependency graph. When source code changes, the compiler compares ZIR source hashes, finds invalidated units, and re-analyzes only what changed.

The post traces a concrete example: changing const lucky_number = 42; to 43 in a short Zig program. The compiler detects the hash change on the lucky_number declaration, re-analyzes its value, then cascades to re-analyze the two functions that depend on that value -- and stops there. The dependency graph prunes everything else.

Code generation converts semantic analysis output (AIR) to MIR (Machine Intermediate Representation). It is also embarrassingly parallel and operates at function granularity, so incremental compilation is straightforward: only re-compile the functions whose AIR changed.

Linking is the hardest part and where the post's most novel work lives. Rather than using a separate incremental linker (the "wild" project has explored this but without a concrete timeframe for incremental support), Zig tightly integrates its linker with the compiler. A custom MappedFile abstraction memory-maps the output binary and tracks a tree of nodes. When a function's machine code needs updating, the linker resizes its node in the mapped file. If there is no room, other nodes get moved -- and a "dirty" flag triggers the necessary fixups (address reassignment, relocation re-application). Exponential growth factors on nodes amortize moves so they are rare in practice.

The post includes Tracy profiler output showing a 37ms incremental update of the Fizzy pixel editor. Of that, roughly 1.6ms goes to the core pipeline (semantic analysis, codegen, linking) and 30ms to resolveReferencesInner -- a graph traversal that determines which declarations are still referenced. As mlugg notes, this traversal did not even need to run (the reference graph had not changed), making it a clear optimization target.

What HN Is Saying#

The 172-comment thread on Hacker News (read it here) spans compiler design, language tradeoffs, and the state of incremental compilation across the industry.

The top-voted thread came from applfanboysbgon: "It disappoints me how unseriously the industry has taken compilation speed for so long. I'm glad to see Zig doing incredibly valuable, high-impact work here." This sentiment recurred throughout the thread -- a sense that the mainstream has accepted slow rebuilds as inevitable and that Zig's work challenges that assumption.

steveklabnik, a prominent Rust core team member, weighed in with measured praise: "Zig's toolchain work is continually impressive. While I still don't plan to write software in it, given that I believe memory safety is table stakes, all of this stuff is very, very good." He noted that before incremental compilation, it was Zig's cross-compilation work that stood out. This is a notable endorsement from someone whose project competes in the same systems-language space.

afdbcreid, a rust-analyzer team member, provided a detailed comparison: "Rust famously has not less (or even more) sophisticated system for incremental compilation, yet its compilation is way slower. I attribute that to two main things: language design (Zig was designed for fast and incremental compilation, Rust is just not) and four properties (layout, type, value, body) that the compiler has to track." This is a nuanced take -- Rust's incremental compilation infrastructure is arguably more mature, but the language itself makes it harder to realize the same speedups.

thefaux questioned the design of building a single giant binary for debug builds, suggesting shared libraries at file granularity instead. The author responded that this approach has its own tradeoffs and that Zig's current approach works well for their use case.

muth02446 raised concerns about the complexity cost of the incremental linking approach: "The incremental linking part sounds pretty hackish to me and I wonder what the price is in increased code complexity and maintenance effort." Author mlugg acknowledged the tradeoff but argued that the MappedFile abstraction cleanly separates concerns and can be improved independently.

Several commenters drew comparisons to other compilers -- Roslyn (C#), the JVM, and Smalltalk environments -- noting that incremental compilation is a solved problem in some ecosystems but remains rare in native-code systems languages.

Why It Matters#

This post matters for three reasons.

First, it shows what deliberate language design for fast compilation looks like. Zig's four-property analysis unit model (layout, type, value, body) was not an accident. Language features were adjusted -- sometimes controversially -- specifically to make incremental compilation tractable. This is a valuable data point for any language designer: fast compilation is a design goal, not an optimization pass.

Second, the numbers are real and they are good. Five-second cold builds with 50-70ms incremental rebuilds on a real application (Fizzy, a pixel editor) are not a synthetic benchmark. The Tracy data shows 37ms end-to-end including a known-inefficient graph traversal that the team plans to optimize. This is competitive with or better than interpreted-language hot-reload workflows while producing native binaries.

Third, the work is not done. The post is refreshingly honest about what remains: resolveReferencesInner dominates the profile, the ELF linker backend only targets x86_64-linux at maturity, and the full disk-cache persistence (so you can close and reopen the compiler without a cold build) is not yet shipped. The team's transparency about these gaps makes the achievement more credible, not less.

For developers watching the systems programming landscape, this is a concrete answer to the question "how fast can native compilation actually get?" The answer appears to be: fast enough that you stop thinking about it.

FAQ#

How fast are Zig's incremental rebuilds?#

On the Fizzy pixel editor, the post reports five-second cold builds and 50-70ms incremental rebuilds. A Tracy profile of one 37ms update shows roughly 1.6ms in the core pipeline and 30ms in resolveReferencesInner, a graph traversal that did not need to run for that change.

How does the Zig compiler decide what to recompile?#

Semantic analysis is split into four kinds of analysis units: the layout of a struct or union type, the type of a container-level declaration, the value of a const declaration, and the body of a runtime function. Each unit tracks its dependencies, so when ZIR source hashes change the compiler re-analyzes only the invalidated units and the units that depend on them.

How does Zig's incremental linker work?#

Zig integrates its linker tightly with the compiler. A MappedFile abstraction memory-maps the output binary as a tree of nodes; when a function's machine code changes, its node is resized, other nodes are moved if there is no room, and a dirty flag triggers fixups such as address reassignment and relocation re-application.

Why is Rust's incremental compilation slower than Zig's?#

In the HN thread, rust-analyzer team member afdbcreid said Rust's incremental system is not less sophisticated, and attributed the gap mainly to language design: Zig was designed for fast and incremental compilation, and Rust was not.

What is still unfinished in Zig's incremental compilation?#

The post lists three gaps: resolveReferencesInner dominates the profile, the ELF linker backend only targets x86_64-linux at maturity, and full disk-cache persistence, which would let you restart the compiler without a cold build, has not shipped yet.

Continue Reading#

• free-compilers-textbook-douglas-thain -- Another HN-front-page compiler deep-dive: a free textbook that walks through building a real compiler from scratch.
• vercel-scriptc-typescript-native-compiler-hn-analysis -- Vercel's Scriptc takes a different approach to fast native compilation, producing TypeScript binaries without a JS runtime.
• typescript-7-native-compiler-migration-guide -- Microsoft's TypeScript 7 native Go port delivers 8-12x faster builds with a very different architecture.
• mitchell-hashimoto-ghostty-zig-interview -- Mitchell Hashimoto on why he chose Zig for Ghostty, including its cross-compilation capabilities.
• roc-rust-to-zig-rewrite-feldman -- Richard Feldman's experience rewriting Roc's runtime from Rust to Zig, offering a practical perspective on the language.
• Zig Creator on the Bun-to-Rust Rewrite: What the Controversy Reveals

Sources#

• Inside Zig's Incremental Compilation - mlugg -- Primary article, published July 28, 2026
• Hacker News Discussion -- 244 points, 172 comments as of July 29, 2026
• Zig Issue #1535 - Incremental Compilation -- Original feature tracking issue
• Zig 0.16.0 Release Notes -- Official release documentation