Highly object-oriented code makes extensive use of memory allocation; I suspect this to be a general rule. Java almost forces you to use this style, so conseque

Highly object-oriented code makes extensive use of memory allocation; I suspect this to be a general rule. Java almost forces you to use this style, so consequently, I expect that the GC is highly optimized for it, and GC is lazy, which cuts the cost of deallocations. I can't see any reason why manual memory management with new/delete, malloc/free, etc, couldn't be done lazy, also, but I think it usually reclaims memory eagerly, and gives a different trade-off (i.e. delete/free are implemented eagerly inside the standard library, rather than just marking the memory and returning). If you want the highest performance, you'll allocate memory in large blocks and take it out of the hands of the GC or library. PS. I can't swear to it that you could do a decent lazy delete or free and get better performance in C or C++, but it doesn't sound absurd on its face. What the standard library could not do is run its own background thread and update memory structures asynchronously, the way some advanced GCs do. But the whole problem can be avoided by doing fewer allocations in the first place, and performance will be consistently good no matter what the platform.