The Influence of Method Call Recording Filters on Hotspots

   


1. Introduction

The notion of a performance hot spot is not absolute but relative to your point of view. The total execution time of a method is not the right measure, since in that case your main method or the run() method of the AWT event dispatch thread would be the biggest hotspots in most cases. Such a definition of a hotspot would not be very useful.

At the other extreme one could use the unfiltered inherent time of the execution of a method for the ranking of hotspots. The unfiltered inherent time is the total time minus the time spent in all other method calls. This would not be very useful either, since the biggest hotspots will most likely always be core methods in the JRE, like string manipulation, I/O classes or core drawing routines in obscure implementation classes of the AWT.

As the above considerations make clear, the definition of a hotspot is not trivial and must be carefully considered.

2. Definition of a hotspot

Only with filters is it possible to come up with a useful definition of a hotspot. Usually, your method call recording filters will be set up in such a way that all library classes and framework classes will be filtered out. In the following discussion, we're going to assume that this is the case.

In order to be useful a hot spot must be

Which one of these viewpoints is more helpful depends on the actual situation. JProfiler's hotspot view offers both modes with the combo box in the top-right corner. The allocation hotspots views also offer this mechanism of adjusting the definition of a hotspot.

3. Example

Let us profile the animated Bezier curve demo that comes with JProfiler. We will try out different filter settings and check how they influence the list of hotspots. In this case we consider the BezierAnim class to be "our" code, while the JRE classes are library classes.

We start by using the "Maximum detail" profiling setting template. Here, full instrumentation is used and no filters are applied.

As we can see, most of the hotspots are implementation classes in sun.* implementation packages. Theses classes are never called by our code. While we could open the backtraces and see how they have been invoked, this is cumbersome and produces no insight into any performance problems that we might be able to solve.

In the next step, we restrict our filters so that only BezierAnim and the java.awt.* packages are unfiltered. This viewpoint is a little strange, somewhat as if the java.awt.* belonged to our code, too. But we want to show how the inclusion of filters changes the hotspots, so we take this middle step. We do this by customizing the "Maximum detail" profiling setting template and entering BezierAnim, java.awt.* as inclusive filters.

Again, there are a lot of filtered classes in the list of hotspot, but while the first two hotspots have stayed the same, the list below them is completely different to the unfiltered case.

Since we now have filters, we can change the viewpoint further by choosing the "add times to calling class" option in the top-right combo box labeled "Filtered classes".

Now, the list has changed completely and we only see unfiltered classes.

Finally, we profile with the "All features enables, high CPU profiling detail" option, where all classes in the JRE are filtered.

Any of the methods that appear in the list of hotspots have been called from our code. This is great for finding performance bottlenecks but sometimes we only want to see our own methods. Again we choose the "add times to calling class" option in the top-right combo box labeled "Filtered classes".

All but one method are directly from the BezierAnim class. The java.awt.EventDispatchThread.run() method is an upward filter bag. It contains framework calls that are executed before any method in our own code is called. This is why it cannot be included into any of our methods.

From the above example you can see how important the filter sets and the definition of a hotspot are for the actual results in the hotspot view. The same considerations apply to the allocation hotspot view.