[codesushi42]

>we know naive C++ might spend more time in memory management code than a GC language.

That's not really true anymore after the introduction of smart pointers. Basically C++ implements reference counting to manage memory as a result.

[ncmncm]

Smart pointers make no difference to the time spent allocating and freeing memory.

But we know that GC always imposes huge costs that point benchmarks uniformly fail to reveal. Often the costs are tolerable, or even negligible. At issue is the set of recourses available when they turn out not to be.

[codesushi42]

In what regard? GC just amortizes the cost. But memory allocation doesn't fundamentally work any differently.

In fact, it can be worse in Java because you have no control over whether an object lives on the stack instead of the heap.

[ncmncm]

No. GC imposes expense in addition to actually managing the memory in use, or newly not. If that were not true, there would be no reduction in hardware footprint after a rewrite.

Make no mistake, rewriting is a huge expense, rarely embarked upon without readily demonstrated benefit. (Exceptions tend to be rewrites in Java for organizational / political reasons. But I digress.) Not spending the time, instead, adding features, and delaying new features until there is a place to put them, can dwarf the base cost of the rewrite. That rewrites are done frequently enough to be discussed tells you there are huge operational benefits available.

[codesushi42]

The OP mentioned nothing about organizational costs, I was talking purely about performance. The OP was incorrectly claiming you'd spend more time in C++ allocating memory, not less.

[weberc2]

Your argument is puzzling. Reference counting is a particularly slow kind of GC. It makes you spend more time freeing memory, not less. And it does nothing to reduce the cost of allocations either. On the contrary, a generational GC can allocate short-lives objects virtually for free—much better than the system allocator. The advantage C++ does have is the ability to control memory such that you can write memory reclamation code that is optimized to your particular application, leveraging information that simply isn’t available to a GC.

[weberc2]

Well said, although that's not the only thing at issue; the prominent tradeoff for that generally smaller (or less powerful) set of recourses is that you have easy, automatic memory management for the default case. I.e., you don't need to make decisions about how memory is managed unless you need to make those decisions. In C++ and Rust, you have to constantly make those decisions (which kind of pointer to use, where will it allocate, what happens to ownership, how will this affect callers, etc).

[wbl]

"We know". Where is the evidence?