Is it just me or does every GC is faster argument boil down to: "All working real world examples are noticeably slower, but trust me, I know of this amazing GC that's actually faster it's just not in production use anywhere yet."
That hasn't been my experience at all. The JVM garbage collector kicks ass today, right now in real applications all over the world, and the next one is going to be even better. There is very likely a class of application out there where extreme micro-optimization is still a good tradeoff (Google's search maybe?), but anyone arguing that they really need to write it in C and do their own memory management carries the burden of proof these days, not the other way around.
In fact many would argue that for small, short-lived objects that the Sun GC outperforms malloc/free. This is a topic of debate, obviously.
Yeah, for Google most of the code that runs when you do a search is C++. (There's a lot of backend servers that handle different things so it isn't 100%, but the core search engine is definitely C++.) It's not just that it's extremely micro-optimized... the general issue is that when your code is running on enough machines it's more often a good tradeoff to spend programmer time to increase performance.
Exactly. Spending programmer time to gain some marginal improvement in CPU cycle efficiency is almost always a bad call, except when that code is going to run on a GAJILLION CPUs all of which use a lot of electricity etc.
I still think that this is only the case for a tiny fraction of all the code out there (Java is f*ing fast these days), and will become less and less true with each passing year.
As always, it depends. For most cases, Garbage Collection is faster than malloc/free. On some platforms, Java can allocate objects in like 3 instructions. It does this because garbage collection allows for optimizations that simply aren't possible using manual memory allocation.
Of course, there are apps that require manual memory management, but they are becoming few and far between.
