|Bruce Eckel's Thinking in Java||Contents | Prev | Next|
1. Install your own instrumentation
“Profile” code by inserting explicit timing:
long start = System.currentTimeMillis(); // Operation to be timed goes here long time = System.currentTimeMillis() - start;
Have an infrequently-used method print cumulative times out to the console window with System.out.println( ). Since the compiler will ignore it when false, a static final boolean switch can turn the timing on and off so the code can efficiently be left in place in released code, ready for emergency use at any time. Even when more sophisticated profiling is available, this is a convenient way to time a specific task or operation.
System.currentTimeMillis( ) returns time in 1/1000ths of a second. However, some systems with time resolution less than a millisecond (such as a Windows PC) need to repeat an operation n times and divide the total time by n to get accurate estimates.
2. JDK profiling 
The JDK comes with a built-in profiler that keeps track of the time spent in each routine and writes the information to a file. Unfortunately, the JDK profilers have uneven performance. JDK 1.1.1 works, but subsequent releases have had various instabilities.
To run the profiler, use the -prof option when invoking the unoptimized versions of the Java interpreter, for example:
java_g -prof myClass
Or with an applet:
java_g -prof sun.applet.AppletViewer applet.html
The profiler output is not particularly easy to decipher. In fact, in JDK 1.0 it truncates the method names to 30 characters, so it might not be possible to distinguish between some methods. However, if your platform does support the -prof option, either Vladimir Bulatov’s HyperProf  or Greg White’s ProfileViewer  will help interpret the results.
3. Special tools
The best way to keep up with the exploding field of performance optimization tools is through a Web site such as Jonathan Hardwick’s Tools for Optimizing Java  at http://www.cs.cmu.edu/~jch/java/tools.html.
Tips for measuring performance
- Since profiling uses clock time, make every effort to remove other processes during the measurement.
- Always time the code before and after making changes to verify that, at least on the test platform, your changes improved the program. (Jon Bentley mentioned that some of his most logical changes actually slowed the program down.)
- Try to make each timing test under identical conditions.
- If possible, contrive a test that doesn’t rely on any user input to avoid variations in user response that can cause the results to fluctuate.