We have written proof-of-concepts for how incremental rebuilds will work in the Zig compiler, which can achieve incredible speed. Let's say you change a single

We have written proof-of-concepts for how incremental rebuilds will work in the Zig compiler, which can achieve incredible speed. Let's say you change a single constant value in a function (e.g. you change a string). The rebuild process looks something like this: * We re-run the `AstGen` pass on the modified file, which is responsible for generating our first IR. `AstGen` is pretty fast - on a ~38k line file, it takes 0.25s on my laptop, so we can guess that for a ~1k line file (much more typical) it'll take under 10ms. * We identify changes and do some logic on the dependency graph of functions and declarations to figure out what might be outdated. In this case, we would find that only the changed function is outdated. * We re-run semantic analysis (`Sema`) on that function. For a small function, this is a trivial amount of time, probably on the order of a single millisecond. This generates our second IR. * We re-run `CodeGen` on the updated IR for this function. This will take a similar amount of time to `Sema`, perhaps around 1ms. * We directly perform the necessary patches to the final binary; appending the new machine code to the binary, updating the GOT entry to refer to it, and updating any modified debug info. This whole process is on the order of milliseconds. This is not hypothetical: this is just how long the compiler pipeline takes to do certain things. We have a lot of work to do with tying these bits together for incremental rebuilds to work, but I do not predict any big losses compared to this performance estimate.