email article printer friendly

Product Review: JProbe
Profile your code and find its problem areas.
by David Thielen

Posted May 6, 2003

One of the tools I used religiously in my C++ days was VTune from Intel. It's an awesome code profiler that would take you down to the instruction level.

Java is a different beast, because you can optimize at the algorithm and architecture level (always the best place), but you don't get down to what's happening in the CPU. Moreover, Java is much more likely to have performance problems from constant allocation and freeing of objects than C++. So a Java profiler needs to handle new things.

JProbe is a profiler designed from the ground up for Java, and only for Java. And it does its job perfectly.

Take the standard performance profiling. You run your code while JProbe takes snapshots N times a second. These snapshots include the callstack at the time of the snapshot. This gives you two key items: how much time your program spends in a piece of code and how much time it spends in a method or a method called by that method. For example, when I ran it against one program I wrote, it spent most of its time in the JVM method for constructing new classes. That's no help—I don't control that code, and that particular code has probably been highly optimized.

But a couple of levels up the call stack I found the real culprit. I had a method that was creating more than 200 member objects (for a visitor pattern). By looking at which methods took how long, including calls to other methods, I quickly found the real problem. (And quickly fixed it by making those 200 member objects static, so they had to be created only once.) In another case, one method was 14 percent of the total program time (for a medium-sized server app). By reworking the algorithms, I got this method down to 2.3 percent of the total time.

Without a profiler, I probably would never have guessed the first problem. Using the profiler in the second case, I knew to spend all of my time optimizing that one method exclusively.

JProbe made the discovery effort almost painless. You see the methods and their time in tables that you can sort by time in the method or by time in the method and the methods it calls, and you have a graph that shows you the call tree based on time spent in each method (see Figure 1). At first I viewed the graph as eye candy, but I found that it was a good way to drill down through the call stacks to find the real source of a performance bottleneck.

Figure 1.

JProbe's memory debugger is not as easy to use as the performance analyzer, but it points you at objects that might be the problem. For example, if there is an object that your program will never use again and it's assigned to a variable, then it will never be freed. If you create one of these every second and never free them, soon you've got a problem. Or let's say you create an object every time a certain event fires and then free it (assign null to the variable) a short time later, and you create 10 of these every second (say for each missile graphic object in a game being fired). In that case, you'll bring the garbage collector to its knees and fragment memory like crazy.

Basically, JProbe's memory debugger gives you a call tree of the objects your application has in existence at any point. You can then trace that tree to see if anything is still alive that shouldn't be.

JProbe also identifies methods that create many short-lived objects. Usually this is a place where you need to recycle your objects. Other features of JProbe include a thread analyzer and a code coverage analyzer.

By using JProbe to profile your code, you can find the hotspots. And once you fix the hotspots, your code will run faster.

About the Author
David Thielen has been programming and managing programmers for 20 years, mainly for startups. His Web page is at .