Locating
the bottleneck
Three
approaches to locating the performance-critical part of a program are:
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 [2]
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 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
[3]
or Greg White’s
ProfileViewer
[4] 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
[5]
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.
|
 
|
![[Internet Jobs]](http://www.codeguru.com/jobs.gif)
