[adwn]

> […] Zig was still using the bootstrap compiler written in C++ that would not free memory […]

That sounds strange. Modern C++ requires very little manual memory management, at least when you're writing something high-level like a compiler. C++11 had been out for years when development on Zig started. Were they writing C++ old-school as C-with-classes and malloc() everywhere? Why not use a more appropriate language for the first prototype of a compiler for a brand new language?

[messe]

IIRC, it was a performance thing, and it's not an uncommon pattern in CLI tools. Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?

[adwn]

> IIRC, it was a performance thing […]

Why would you care about these kinds of micro-optimizations at that stage of development, when you don't even know what exactly you need to build? We're not talking about serious algorithmic improvements like turning O(n²) into O(n) here.

> Freeing memory can actually cost you performance, so why not just let the OS clean up for you at exit(2)?

Because a compiler is not some simple CLI tool with a fixed upper bound on resource consumption.

[throwawaymaths]

> Why would you care about these kinds of micro-optimizations

it turns out that compiler speed is bound by a bunch of things, and it's death by a thousand cuts. If you have a slow compiler, and it takes forever to compile your compiler, your language becomes scelerotic, no one wants to make changes, and your language gets stuck in shitty choices.

> Because a compiler is not some simple CLI tool with a fixed upper bound on resource consumption

yes. thats right. a compiler is complex and should use several different allocation strategies for different parts. if your language steers you towards using malloc for everything then your compiler (assuming it's bootstrapped) will suffer, because sometimes there are better choices than malloc.

[adwn]

You're losing sight of the full picture: This "optimization" was such a hindrance that they had to rewrite the compiler before they could work on the ecosystem of their new language. From kristoff_it's comment [1]:

> When I first joined the Zig project, Zig was still using the bootstrap compiler written in C++ that would not free memory (it took more than 4GB to compile the Zig compiler). Some people at the time were asking us to prioritize work on the package manager but Andrew rightfully wanted to prioritize rewriting the compiler instead. In hindsight this was the obviously right decision: a package manager implies that one can very easily add an order of magnitude more code to their project, stressing the performance of the compiler. If we had not prioritized core infrastructure over giving people what they wanted faster, today we would have people complaining that adding a single dependency to their project makes the build impossible to complete.

[1] https://news.ycombinator.com/item?id=44994886

[messe]

> they had to rewrite the compiler before they could work on the ecosystem of their new language.

I think you may have missed that the intention was always to rewrite the compiler to become self hosted. Improving the C++ implementation any more would've been pointless optimization.

[throwawaymaths]

no. a global arena is not the right solution for every project. but believe it or not, the zig compiler does use arenas as one of its strategies (just not global arenas), so yes, access to that strategy for performance improvement is still important and absolutely being used in the zig compiler today.