Background

Remember that most computers spend virtually all their time waiting for the user to do something... and most of the rest of the time waiting for another computer, a network, or I/O device to do something! Developers are notoriously bad at guessing where time is actually spent, so it's a good idea always to do some measurements before writing contorted or difficult to maintain code in the supposed interests of performance.

Profiling techniques

There are several techniques for profiling Java code:

Add timing support within your code
```
long start = System.currentTimeMillis();
... do something ...
long end = System.currentTimeMillis();
System.out.println("Did something, took "+(end-start)/1000.0+"s");
```
Although this involves code changes and recompilation, this method is very flexible. It provides accurate absolute times for how long a section of code takes, and is the only technique that can be used to analyse where time is spent within a method.
Use profiling support built into the Java virtual machine and view the output with profile viewer.
This has the advantage that no code changes are needed, and it's free! It also works with any JVM and platform, not just those supported by tool vendors. The main disadvantage is that only the immediate caller of a method is logged, so all invocations of a method tend to be rolled into one, irrespective of where in your code it's used, which makes it very difficult to analyse particular situations.
Use a commercial tool such as OptimizeIt or JProbe
These use the low level JVM debugger API to monitor what the virtual machine is doing. OptimizeIt has two modes, sampling mode (where it lets the application run but periodically samples which method it's in) and instrumentation mode (where it traps each call as it happens). These provide much more detail on a particular execution path through your code, overcoming the deficiencies of built in profiling. However, sometimes the sheer volume of data produced is overwhelming and a simpler approach is all that's required.
Use other Hotspot profiling options
The Hotspot (JDK 1.3) VM has several other profiling options, eg. to provide statistics on how well the compiler is performing, but I haven't looked into these in detail yet. Type "java -X" or "java -Xrunhprof:help" for details.

Caveats

Any of the techniques that trap method calls will lead to slight distortions in the timing as native methods or code involving system calls will execute at normal speed wheras code involving many Java method calls will be slowed by nearly a factor of three.

Why is so much time spent in Object.wait()? This is where a thread spends all its time when it's waiting for another thread to finish or for I/O to complete, including waiting for the user to press a key or move the mouse, so it's almost always guaranteed to be the method at the top of the list. In general, you won't get any very meaningful results from analysing the wait() method and should start instead by analysing a method you know is significant in your code.

History

This application was originally a Perl script, then given a user interface in early 1998 when Swing was still in beta and using the com.sun.swing package name. Only recently was the dust brushed off, a standalone version of the Java2 collection classes added (so it runs with JDK1.1.8 releases), and then made available for download.

Help index | Start over