Granularity

Shall we present information at the method call level, or at a finer granularity such as basic blocks or different execution paths inside a method? Based on our experience with tuning Java applications, we believe that there is little reason to attribute cost to a finer granularity than methods. Programmers typically have a good understanding of cost distribution inside a method; methods in Java applications tend to be smaller than, for example, C/C++ functions.

It is not enough to report a flat profile consisting only of the portion of time in individual methods. If, for example, the profiler reports that a program spends a significant portion of time in the String.getBytes method, how do we know which part of our program indirectly contributed to invoking this method, if the program does not call this method directly?

A good way to attribute profiling information to Java applications is to report the dynamic stack traces that lead to the resource consumption. Dynamic stack traces become less informative in some languages where it is hard to associate stack frames with source language constructs, such as when anonymous functions are involved. Fortunately, anonymous inner classes in the Java programming language are represented by classes with informative names at run time.