[pjlegato]

If your optimization goal is "use the least memory possible," then sure, manual memory allocation is the way to go. I was addressing a different optimization goal: the "high performance" case, meaning approximately "high throughput, low latency operation."

There is a common misconception that GC invariably precludes the construction of a "high performance" system, which is not true. If your use case allows you to not care as much about larger memory consumption -- 2x to 3x does seem like a reasonable first approximation of "larger" -- then GC is indeed a viable option for building "high performance" systems.

This case is not uncommon. Not everyone is targeting a memory constrained console or embedded system.

In many (though of course not all) cases, the tradeoff is well worth it -- consume more memory at runtime, spend some time tuning the GC, and in exchange developers can ship a product faster, by having to spend significantly less time dealing with manual memory allocation.

[learc83]

>If your optimization goal is "use the least memory possible," then sure, manual memory allocation is the way to go. I was addressing a different optimization goal: the "high performance" case, meaning approximately "high throughput, low latency operation."

Ignoring the amount of memory used, GC tuning a managed language doesn't give you the flexibility to control memory layout needed for maximum cache locality.

>If your use case allows you to not care as much about larger memory consumption -- 2x to 3x does seem like a reasonable first approximation of "larger" -- then GC is indeed a viable option for building "high performance" systems.

Not ignoring amount of memory used. In the context of this thread--video games specifically "high performance" video games--2x to 3x is almost never going to be acceptable.