[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.