Cover Story (sidebar) / May 1998

Speed Tips for Java Coders

Tom R. Halfhill

Java developers don't have to wait for fancy new compilers and other whizbang technologies to make their programs run faster. It's possible to achieve major gains in performance simply by writing (surprise!) better code.

Strangely enough, Sun engineers discourage programmers from using too many clever tricks. As Java evolves, some tricks won't work anymore, they point out. "In effect, you're writing to a specific VM implementation, and that doesn't make sense. You're doing damage to your code," says Tim Lindholm, a senior staff engineer at JavaSoft and coauthor of The Java Virtual Machine Specification (Addison-Wesley, 1997).

This is especially true when the tricks compromise good object-oriented program (OOP) design. For example, liberal use of Java's final keyword does make programs run a little faster, because the JVM knows a program can't subclass final classes, override final methods, or alter final data members. But final makes code reuse more difficult -- and code reuse is what OOP is all about.

"There's a lot of pretty rotten code being written out there," says Collette Coad, the U.S. leader for Java-based computing at Ernst & Young. "People attend a few Java courses and then revert back to old habits. They're writing scripted Java programs or procedural Java programs. They're not embracing the concepts of OO."

You're better off studying good design and algorithms -- classic computer science. However, if you absolutely must squeeze the last drop of performance out of Java, here are some tips from experts:

• Strings are slow. Use StringBuffers or char arrays instead. String concatenation is particularly costly, because the JVM must convert the String constants into StringBuffer objects, join them together, and convert them back into Strings. -- Doug Stein, an engineer at Active Software, who created the GridBag Layout manager while at Sun

• You have control over dynamic class loading. If you'd rather take the hit when a program first launches, initialize all objects immediately, even before you need them. Or delay class loading by not creating objects until later. -- Stein

• It's possible to write better class loaders. Borland JBuilder, which is 80 percent Java, starts up faster because Borland improved Sun's class loader. -- Jayson Minard, JBuilder product architect

• The new Java Foundation Classes (JFC) are faster than the Abstract Window Toolkit (AWT) because they're not bogged down by as much thread synchronization. Also, JFC components are pure Java -- easier to compile. -- Minard and Tim Freehill, engineering manager for Metrowerks CodeWarrior

• Don't create a lot of temporary objects; they make more work for the garbage collector. Avoid creating objects locally within loops or frequently executed methods. -- Paul Tyma, president and chief scientist of Preemptive Solutions

• If all objects of a class require some identical initialization code, put that code in a static initializer, not a constructor method. It will execute only once. -- Richard M. Fogel, technical product manager for KL Group's JProbe

• Find bottlenecks with a profiling tool. Examples are JavaScope (SunTest), JProbe (KL Group), OptimizeIt (Intuitive Systems), TrueTime (NuMega), Visual Quantify (Rational Software), and VTune (Intel).

Probing Builds a Profile

Screen photo of a
                  Java code-profiling tool.
A profiling tool such as KL Group's JProbe can show which classes and methods a Java program calls most often.

Copyright © 1994-1998 BYTE

Return to Tom's BYTE index page