[jharsman]

Garbage collected systems typically implement allocation with a simple pointer bump. This is possible because values are moved in memory by the garbage collector, updating references automatically. You can then compact all the empty space when collecting garbage, making allocation easy.

This is obviously faster than malloc which is what people compare with when they say allocation is faster with a garbage collector. Collecting the garbage, i.e. de-allocation, can be more expensive though, since it might require scanning large parts of the heap.

Since games generally use region based allocators , the performance gain is probably very small there. If you make lots of calls to malloc, then the gain would be larger.

[bitwize]

But you pay for it on the back side when it comes time to, heh, collect. There was a paper which suggested it takes five times as much RAM for a GC'd program to equal the coorespondng manual-allocator program in terms of performance: Hertz and Berger's "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management".

If you care about performance you will avoid the garbage collector like the plague. Best to write it in C, C++, etc.

[Evbn]

Yes, the entire topic of this thread is that by spending more RAM on GC, you can save CPU for memory management.

[bitwize]

But you don't actually save that much CPU and it's certainly not worth having to spend five times your working-set size just to equal explicitly-managed memory in performance terms.

Seriously, if you want cheap allocations use a freaking allocation pool. They're not that hard to implement in C++.

[qznc]

Between malloc and garbage collection is obstack. Allocate by pointer bump and free a complete stack at once. For example, used in compilers for AST nodes etc.

[seunosewa]

So, 1) Change your program so it uses lots of mallocs. 2) Switch to a garbage collector to make your program faster!