## The influence of call tree collection filters on hotspots |
previous | up |

### 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.

As 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 call tree collection 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

- a method in your own classes
  This can be obtained by measuring hotspots with the inherent time of a method call plus the calls into filtered classes.
- a method in a library class that you call directly
  Since filters are endpoints for the measurement of methods, the inherent time of a filtered method is equal to its total execution time. When simply measuring hotspots with this filtered inherent time, filtered classes will likely be the hotspots.

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.