[jandrewrogers]

The software performance gap between modern GC code and non-GC code is still pretty large almost everywhere. GCs make entire classes of optimization effectively impossible. At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code.

GCs are useful in the same way that Python is useful even though it is slow. Simplicity of use has intrinsic value but that is a tradeoff against other objectives.

[sfink]

I agree that GC code can be and usually is slower. But as a counterpoint: allocation can be very slow. Bump allocation is fast. If you know your lifetimes and can free all of your bump-allocated memory in one go, that's pretty much the best you can do. If not, then you can still bump-allocate, but copy away the live stuff while discarding the rest. You keep bump allocation, you may even improve locality by eliminating the fragmentation in your bump allocation arena. On the other hand, you've written a garbage collector and thus inherit the disadvantages of GC.

My point is that you can start out without a GC and do a series of sane and effective optimizations that end you up with a GC. Just as you can start with a GC and optimize by moving more and more of your allocations to non-GC memory and end up without a GC. Which endpoint is faster depends on the workload.

[Someone]

> At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code.

You can say the same about any abstraction, such as having a generic memory allocator, using a standard library, actually about any code reuse. For example, many programs use printf, but don’t need all its features, so hand-rolling a custom version may lead to smaller, faster code (things get complicated here on systems with shared libraries)

The question always is whether lost performance (execution time, memory usage) is worth faster development.

[nitwit005]

You're making a new argument that's entirely different than the one they're responding to.