Sponsored Link •
This article describes the "popular lore" that aims to improve the performance of Java programs in ways that reduce the flexibility of the code, and describes Sun's Hotspot JVM in technical detail. The article shows how Hotspot attempts to eliminate the performance bottlenecks that gave rise to the "popular lore" in the first place.
According to Sun Microsystems, the Hotspot virtual machine, Sun's next-generation Java virtual machine (JVM), promises to make Java "as fast as C++." Specifically, Sun says that a platform-independent Java program delivered as bytecodes in class files will run on Hotspot at speeds on par with an equivalent C++ program compiled to a native executable. If Sun is able to make good on this claim, the current performance penalty of delivering or using a Java program will go away, at least as compared to C++. But Hotspot has one other implication important to developers: Hotspot promises to alleviate concerns that creating good object-oriented, thread-safe designs and good-quality, maintainable code will degrade performance.
To date, one of the major tradeoffs of selecting Java over other languages has been performance. The original Java virtual machines, which simply interpreted bytecodes one at a time, were clocked at 30 to 50 times slower than natively compiled C++. Just-in-time (JIT) compilers have narrowed the performance gap to 3 to 10 times slower than C++, but that performance gap is still big enough to eliminate Java as the language choice for certain applications.
Furthermore, the performance situation may continue to have repercussions even after Java is selected for a particular application. Due to Java's performance track record, programmers may be tempted to design their Java programs in ways they think will help boost its performance at the expense of maintainability. The performance characteristics of past and present incarnations of the JVM have given rise to an unofficial lore in the Java community concerning how to design and implement a Java program to give it the best performance. And most of this lore goes against the grain of creating good object-oriented, thread-safe Java code.
The fundamental principle of optimization is: Don't optimize until you know you have a problem. As Donald Knuth once said, "Premature optimization is the root of all evil." In general, you should forget about optimization and just create good quality designs and clear code. After you get your well-designed program working, if you then find that its performance is lacking, that is the time to optimize.
Another basic principle is: Measure the program before and after your optimization efforts. If you find that a particular effort did not make a significant improvement in the program's performance, then revert back to the original, clear code.
A third principle takes into account that most programs spend 80 to 90 percent of their time executing 10 to 20 percent of the code: You should profile the program to isolate the code that really matters to performance (that 10 to 20 percent), and just focus your optimization efforts there.
Once you isolate the time-critical areas of your program, you should first try to devise a better algorithm, use APIs in a smarter way, or use standard code optimization techniques such as strength reduction, common sub-expression elimination, code motion, and loop unrolling. Only as a last resort should you sacrifice good object-oriented, thread-safe design and maintainable code in the name of performance.