[sbanach]

With Java vs C++, the experience seems similar. In C++, memory allocation is slow, so you worry about memory allocation up front. In Java, GC is a pain so you worry about memory allocation up front. As Daniel points out, there are a few extra tricks available to native developers (eg vector instructions), so there's a small factor speed-up in best-practice C++ vs best-practice Java, but this is closing (eg the JIT increasingly uses vector instructions). Overwhelmingly the difference between a slow system and a fast system is appropriate choices of algorithms and architecture, not the language.

[bilbo0s]

>In C++, memory allocation is slow, so you worry about memory allocation up front. In Java, GC is a pain so you worry about memory allocation up front...

This.

A lot of people seem to be willfully dismissive of this reality when they are fanboying for their favorite languages.

Ask for memory in C++, you'll take a HUGE hit getting it. Ask for memory in Java, and you'll get it lightning fast, but you'll take a huge hit getting rid of it. Either way, you should carefully plan memory usage up front.

Basically, one road leads to death and despair, the other leads to disease and destruction...

pray you choose wisely.

[gpderetta]

Any moderately performance sensitive code in C++, assuming it needs allocations at all will use a dedicated allocator.

While it is hard to beat existing general purpose allocators in all the scenarios, it is easy for specific use cases.

[kjeetgill]

True but these approaches in both C++ and Java start to converge: Arena allocation vs Pooling/unsafe. The question is, how annoying is your performance insensitive code?