Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

Question of the month: Static vs. runtime optimizations

Get rid of your performance problems and memory leaks!

Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:

Get rid of your performance problems and memory leaks!

Back to newsletter 042 contents

I read somehere that Java could theoretically run faster than a C program. Is there any truth to that?

Well, since both programs ultimately get executed as machine code on a particular CPU, you could theoretically reverse engineer one such program into the other, and hence get the same performance from either. But more practically, I think you are referring to the fact that Java has a virtual machine which can optimize the program at runtime, whereas C is a statically compiled program. Some people do say that this means the Java virtual machine (JVM) has runtime information that is not available to the static optimizer, and so is theoretically capable of optimizing the program to be more efficient. Are there any practical examples which can show this?

Yes. In an interesting discussion Jeff Kesselman (Sun engineer focused on games) had in his blog, ( see the blog here), Jeff made the following points (my thanks to Jeff for allowing me to use his comments):

Java code (or any run-time compiled code) has the potential to run FASTER then pre-compiled code because it can (and does) factor in knowledge of the operating environment.
Some examples:

In general Java today is C++ equivalent in speed. There are some micro tasks that C will always do better. These involve random access into large byte array fields. Decoding MPEG streams is the classic example. Thats why we ship a JNI based codec with JMF. (Even in this extreme case though it only buys us about 15% speed improvement.)
There are some tasks Java will almost always beat C at. Java allocation and deallocation is lightning fast compared to C. Our better optimization of loops and recursion also seem to, for some reason, result in a FFT that always ends up beating the best C counterpart.

Now before I get the usual bunch of armchair commentators writing desperately in green ink to tell me that they can optimize their C program to be faster than any Java version, let's just clarify this series of points. Java is faster for some things, C is faster for others. You can further optimize your C program for the particular runtime conditions if you know what they are. And no doubt you can spend lots of time analyzing your code to get your allocations and deallocations lightning fast, and your loops and recursive calls equally fast. And I can do the same in Java, spending lots of time hand optimizing code and reducing objects. Until we both end up with Assembler-like versions that are the fastest possible.

But the vast majority of programs, whether C or Java, do not have the person resources do do all that optimization. Maybe you don't have a life, but I sure have better things to do. Your typical program gets the benefit of whatever compiler optimizations or runtime optimizations that are available, plus some hand coded optimizations to get rid of any remaining bottlenecks until the code is fast enough.

And in this type of environment, the JVM runtime optimization can outdo the static optimizations possible for C programs. So, yes, knowing the runtime environment and being able to adapt to that runtime environment allows a class of optimizations that are not available to most statically compiled programs, unless those statically compiled programs have a very well defined target runtime environment that they are being compiled for.

Which all means that the answer to the original question is: yes, there is some truth to it.

The team

Back to newsletter 042 contents

Last Updated: 2017-10-01
Copyright © 2000-2017 All Rights Reserved.
All trademarks and registered trademarks appearing on are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed:
Trouble with this page? Please contact us