Profiling the profilers

A comparative review of three commercial Java code profilers

By Laurence Vanhelsuwé, JavaWorld.com, 08/22/03

Print
Email
Feedback
Resources
Discuss

Digg
Reddit
SlashDot
Stumble
del.icio.us
Technorati
dzone

Modern software is such an unwieldy multidimensional beast that no single development tool can ever hope to give programmers the complete picture of their creations. Even performance—that elusive metric we all love to hate when our code struggles with second gear, and love, when our code travels at O(1) speed—consists of many devilishly interlocked facets.

Performance's proverbial tip of the iceberg consists of the subjective, user-tangible perception of program speed and responsiveness. If we temporarily eliminate the user from the equation, then we can equate performance with the sum effect of objective performance facets such as algorithm choice, overall memory usage, object allocation and de-allocation dynamics, and multithreading design and runtime behavior. Helping you to understand your program's dynamic behavior in these select dimensions is the burdensome job of code profilers.

In this article, I look at three commercial Java profilers and determine which ones come close to satisfying your, and my, needs:

Borland's Optimizeit Suite
Quest Software's JProbe Suite
ej-technologies' JProfiler

Profiler basics

Not surprisingly, all three products have a lot in common. All modern profilers begin from an identical starting point and constraint: the Java Virtual Machine Profiler Interface (JVMPI) (see sidebar, "The Java Virtual Machine Profiler Interface"). This Sun Microsystems API lets tool vendors interface or connect with a JVMPI-compliant JVM, and monitor the workings and key events of a JVM running any Java program—from standalone application to applet, servlet, and Enterprise JavaBeans (EJB) component.

Given that JVMPI imposes a standardized, level playing field for all profiler tool vendors, it is no surprise that the main differentiating factor vendors compete on boils down to the tools' metafeatures (i.e., features that add significant value to raw JVMPI data and functionality, and, even more important, the graphical user interface (GUI) fronting those features).

As you'll see in the rest of this product review, the products' make-or-break GUIs each have an individual approach to the core problem of how to exploit the raw JVMPI features to maximize analytic and debugging productivity. Unfortunately, as for so many applications tasked with visualizing large datasets in an intuitive and truly user-friendly way, not every profiler convinced me that its makers succeeded in that respect.

The three reviewed profilers have almost identical profiling session configuration capabilities, so I briefly mention them here and move on to the comparison:

JVM selection
To-be-profiled program selection
CLASSPATH and source path selection

To start any profiling session, all three products let you select the JVM on which you normally run your application. Once you select a JVM, you must specify your program's main class, or executable jar file, and what arguments, if any, your program expects. Finally, setting the CLASSPATH for a profiling session also typically lets you point the tool at your source code hierarchy. Figure 1 shows a typical session configuration dialog.