What is ppProf?
ppProf is a pretty primitive profiler for Java 5.0 programs. It uses the
agent interface to instrument byte code
during application loading.
What is "primitive" about it?
It doesn't do much. It tries to be as simple as possible, and to
generate as little overhead as possible. Other profilers offer
graphical output, allocation of run time to stack traces, and remote
ppProf just counts method invocations and produces a "flat" profile,
i.e. a list of time spent per method. This alone can make your program
several times slower, depending on the circumstances.
Why does it still
take so long?
My pet example, which takes 1-2 minutes of CPU time when not profiled,
performs about 1155 million method calls on "user" code, i.e. not
counting java.* classes and the like. If profiling introduces
a 1 microsecond overhead per call, that's 1155 seconds additional
runtime when the application is profiled. That's about 20 minutes
extra, or 10 times the original runtime.
The are two obvious counter-measures: profile less methods, and reduce
Profiling less methods
This is partly achieved by application defaults, which can be
overridden, and the restriction to classes loaded by the
SystemClassLoader (hardwired in ProfTransformer,java). For the pet
example, the bulk of invocations are inside the XML parser. After
excluding org.apache.xerces and org.jdom, the number of method calls
drops to 68 million, or by a factor of 17.
Future versions may attempt to attribute time spent in excluded
packages to that package, rather than to the callee.
Reducing the overhead
Reducing the profiling overhead is done by restricting the
functionality to the bare minimum. In particular, ppProf does not
attempt to associate time with "call stacks" like other profilers. It
just eats up cycles and space (since you have to build the call
Also, ppProf doesn't do any heap profiling, or other fancy stuff. And
it calls the timing function only once per method invocation, roughly.
Consequently, ppProf should only very rarely die with an OutOfMemory
error if your settings are not good enough. It should just take longer.
Less obvious problems
I was quite amazed when my AMD X2 4400 Linux box was four times
slower than my tiny sub-notebook with a 1100 MHz ULV Pentium CPU.
This turned out to be an OS issue: The performance of the gettimeofday
system call. SMP slows it down by a factor of ~16 on my hardware. Some
experiements yielded a little JNI quickie to circumvent this.
The last respot
If timing is too slow, you can use an option to just count calls. The
overhead for this is pretty small. Based on the result, you can exclude the most frequently called classes or packages.