Can anyone quantify performance differences between C++ and Java?

Java was initially slow before the JIT but today performance is pretty close to C++. I want to know if someone has done measurable performance comparisons between the two languages? Where does Java fall short when compared to C++? Java provides many productivity gains to developers so they can write applications much quicker because of garbage college, lack of pointers, etc. Applications such as Firefox, Webkit and Open Office, for example, could be developed much more quickly and reliably if written in 100% Java, perhaps by a factor of 2, but developers still choose C/C++ for performance reasons. Can someone demonstrate where Java cannot be made to perform as well as C++ for applications like the ones that I mentioned.

Let me just add that much application work is still being done in C++ for a reason. This is meant to be more than a subjective questions. Languages with higher levels of abstraction frequently pay a performance penalty. We would all be programming in higher level languages if this penalty did not exist. Where does still Java pay in comparison to C++? Be specific.


JIT compilers can be faster for many individual code constructs because they can take advantage of runtime profiling of code.

For example, VonC in his answer to this question mentions heap allocation for all objects. This is not actually true: the JIT can allocate objects on the stack if it can prove by escape analysis that references to the object will not outlive the stack frame. In this way, the compiler can get the performance benefit of stack allocation while the programmer can rest assured of the safety of assumed GC heap allocation.

Similarly, Uri mentions virtual functions (called virtual methods in most non-C++ languages). This is another case that JIT compilers have an advantage that is almost never available to ahead-of-time (AOT) compilers: the JIT can insert an inlined cheap type check (a dereferenced-word comparison) and actually inline a virtual method call if that particular call site happens to be monomorphic (i.e. the actual type is always the same in practice). It turns out that up to 95% of all virtual method calls are monomorphic in practice, so this can be quite a big win - and it's a win that is hard for AOT compilers to take advantage of, since runtime code loading may change runtime characteristics dynamically.

Languages don't have a speed. Neither the Java or C++ language specs specify "and programs must be compiled to be this efficient".

Each language specifies a list of things the program must do, or at least, appear to do, which in some cases put an upper bound on how efficient a program can be, but often, a clever compiler can ignore these rules in individual programs, because all that matters is that the program behaves as if the spec had been followed. Functions can be inlined, heap data can be moved to the stack and so on.

The performance of a program depends on three things: The compiler, the underlying platform/hardware and the program code itself.

Not "the language". The closest you're getting is the compiler.

There are good reasons why either language could be faster than the other. C++ makes fewer promises that could potentially slow down program execution, but Java is JIT'ed, which means it could potentially take advantage of runtime information to optimize the code, which C++ can't easily do... And then again, nowhere in the spec does it say that C++ must not be jit'ed. Just like I believe there are also Java compilers that generate native code instead of JVM bytecode.

Your question only makes sense if you have a specific computer you're running on, a specific compiler for each language, and a specific implementation of your program in each language, in which case you could just run both to see which was fastest.

Garbage collection is another wonderful example. Of course garbage collection implies some overhead, but it also enables some significant shortcuts. Heap allocation is ridiculously cheap in managed languages like Java or .NET, because it is managed and garbage-collected. In C++, it's.... unspecified, of course, but in practice, typically very slow, because the OS has to traverse the heap to find a free block of memory in a more or less fragmented memory space. Which is fastest? Depends on the OS. Depends on the compiler. Depends on the source code.

The source code makes a big difference as well. If you take a Java program and naively port it to C++, it will perform like crap. C++ doesn't deal that well with virtual functions, and usually has superior alternatives available you could use instead. Heap allocation can be very slow in C++, so again, naively reimplementing a Java program would be extremely inefficient. And the same applies when going the opposite way. Many C++ idioms would be needlessly slow if ported directly to Java. So even if you've settled on one platform and one compiler, how do you compare the performance of your program? To even get it to compiler, you have to write two implementations of it, and then it is no longer the same program.

However, I think it's fair to say that on most modern hardware, with a modern Java compiler and a modern C++ compiler, most programs can be implemented to be very efficient, and certainly fast enough. But only if you understand the language you're working with, and play by its rules. If you try to write Java code in C++, then Java will magically turn out to be vastly more efficient, and vice versa.

I guess the most concise answer to your question is "No. No one can quantify performance differences between C++ and Java" ;)

Need Your Help

Rails Testing: Fixtures, Factories, and Magic numbers

ruby-on-rails unit-testing testing yaml

I've got an application that needs quite a bit of data (1000s of records) to do appropriate testing. The only way I've found to get a decent set of testable, sensible data is to use a subset of my

AngularJS doesn't update img src when model changes

javascript html angularjs

I use ng-src to load images. Value is loaded from some scope variable, like this: