JIP – The Java Interactive Profiler
An effective new configurable profiler for Java
Andrew Wilcox
Senior Architect
MentorGen LLC
November 2005
Introduction
This paper will discuss the reasons why Java developers would need to profile their code
and will dispel some common myths about code optimization. It will then discuss how
profilers work and how they can be used to optimize code. We will look at the limitations
of many profiling strategies and how interactive profiling can be used to get a better
picture of how Java code will perform in a production environment. Finally, the Java
Interactive Profiler is described and how JIP meets these needs is described.
Why profile?
Profiling is a performance measurement technique. If your application is slow, it only
makes sense to measure where the code is spending most of its time and attempt to make
that code more efficient. However, if an application is having performance problems,
most developers either go through the code to look for local inefficiencies or will go
directly to the part of the code that they suspect is causing the problem. Both of these
tactics are flawed.
Local optimization is the act of going through the code, line by line, to look for known
inefficiencies. In the Java world there has been a lot said about things to avoid: avoid I/O,
avoid String manipulation, avoid unnecessary object allocation, etc. From the larger
discipline of algorithm analysis, we know how to quantify the efficiency of the
algorithms that are used. But these are local optimizations and may not actually make the
application in question run any faster. Most experienced developers have been on
projects where performance was an issue, and someone has spent days or weeks
optimizing suspect code only to discover that the effort yielded little or no improvement.
In complex applications, you need to look at the performance of the code as a whole and
not the small section of code that you think is the culprit. You can optimize a piece of
code all that you want, but if that code only represents 2% of the total time of a particular
case, you have no hope of significantly improving the performance of you code. There
are people who think that a 2% improvement here and a 5% improvement here will add
up to a signification increase in performance. I call this the nickel and dime approach. It
is almost always less successful than going after the big performance offenders.
The other often-employed tactic to improve performance is to go after that part of the
system that the developer has “always suspected” was slow. I call this the Intuition