[_lbaq]

Heap allocation and smartpointers (as an alternative to GC) is by no means free, in that context GC performance favorable in many scenarios, for example when doing large number of small allocations.

But in the end, if your application have serious performance requirements, you should avoid allocating memory in the hot path altogether.

[_ph_]

So much this. GCs don't mean you shouldn't care about reasonable memory allocations. In hot paths, not allocating will always be faster than allocating. Having a GC does not prevent you from using object pools and buffers, where it is a clear performance win. But having a GC means, you are not required to do so, where there is no bottle neck. The difference between a "fast" and a "slow" GCed language often is, how well the programmer keeps some control about memory allocations.

Fun fact: the Go GC is written in pure Go code, which does not perform any heap allocations. So there is enough control to write code in Go which does not require any heap allocations. There is even a compiler switch for the development of the GC code which makes heap allocations a compile error.