[anon_d]

With only three times as much memory, it runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management.

I don't see how this article is helping your point; that's a pretty massive hit. Even worse, this is a GC-style program modified to use explicit malloc/free. Programming with manual memory management encourages a very different style of programming where you try to use malloc/free as little as possible, and you try keep memory for various things in contiguous chunks of memory.

EDIT:

This comment is interesting: http://lambda-the-ultimate.org/node/2552#comment-38915

[silentbicycle]

They may have had Appel's "Garbage Collection Can Be Faster Than Stack Allocation" (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.39.8...) in mind.

Also, the technique described in that comment (forking processes with finite lifetimes, allocating but not freeing, terminating and letting the OS clean up all at once) is also what Erlang does, and it seems to work pretty well in practice. Each process has its own arena, for allocation purposes.

[chc]

I think it's the discussion that we're meant to read, not just the OP. Most of the comments are pointing out questionable assumptions in the study (e.g. even though they admit that actually changing the program to use manual memory management would be nearly intractable, they assume that essentially running an AOT garbage collector is equivalent).