The 35ms incremental rebuild is the part that sold me. I'd be curious to see the same benchmark on ARM once -fincremental gets there.

Zig team member here---obviously I can't say for sure yet, but I'm pretty confident the number will be basically identical. In the Zig compiler, incremental updates (rebuilds) have a small amount of overhead which is roughly proportional to the total size of the codebase (rather than just the amount of code which was changed). This comes from a) detecting which source files changed, and b) traversing a graph to figure out which declarations are referenced (necessary due to Zig's "lazy analysis" feature). But performance analysis reveals that for small updates, this overhead actually dominates the update time, by a lot. Of the 35ms, I would guess that under 5ms are actually spent rebuilding the function(s) that changed. Of that 5ms, code generation---the only thing which would really be different on AArch64---is an even smaller slice of the pie (it often doesn't even impact the overall time, since it runs in parallel with other parts of the pipeline, and those other parts are usually the bottleneck there). So even if the AArch64 backend was significantly slower (which, right now, is the opposite of what we expect---instruction selection and encoding for x86_64 is unusually complicated!), I wouldn't expect the number to change from 35ms.