In some situations, it's not the average invocation time of a method that is a problem, but rather that a method misbehaves every once in a while. In the call tree, all method invocations are cumulated, so a frequently called method that takes 100 times as long as expected once every 10000 invocations will not leave a distinct mark in the total times.

To tackle this problem, JProfiler offers the method statistics view and the exceptional method recording feature in the call tree.

Method statistics view

The method statistics view shows information about the distribution of call durations to each method. With the histogram of all recorded call durations, you can check if you are dealing with single outliers or a continuous spectrum of durations. The standard deviation and the outlier coefficient that is calculated as (maximum time - median time) / median time can help you to quantify methods in this respect and sort them in the method table.

By default, the graph shows invocation counts on a logarithmic scale. This is ideal for identifying outliers with a low relative frequency. To get a feeling for the real numbers, it may be useful to switch to a linear axis in the view settings.

Configuring exceptional method recording

Once you have identified a method that suffers from exceptional call durations, you can add it as an exceptional method in the context menu. The same context menu action is also available in the call tree view.

When you register a method for exceptional method recording, a few of the slowest invocations will be retained separately in the call tree. The other invocations will be merged into a single method node as usual. The number of separately retained invocations can be configured in the profiling settings, by default it is set to 5.

When discriminating slow method invocations, a certain thread state has to be used for the time measurement. This cannot be the thread status selection in the CPU views, because that is just a display option and not a recording option. By default, the wall clock time is used, but a different thread status can be configured in the profiling settings.

In the session settings, you can remove exceptional methods or add new ones without the context of the call tree or the method statistics view. Also, the exceptional method configuration provides the option to add exceptional method definitions for well known systems, like the AWT and JavaFX event dispatch mechanisms where exceptionally long-running events are a major problem.

Exceptional methods in the call tree

Exceptional method runs are displayed differently in the call tree view.

The split method nodes have modified icons and show additional text:

•  [exceptional run]
  Such a node contains an exceptionally slow method run. By definition, it will have an invocation count of one. If many other method runs are slower later on, this node may disappear and be added to the "merged exceptional runs" node depending on the configured maximum number of separately recorded method runs.
•  [merged exceptional runs]
  Method invocations that do not qualify as exceptionally slow are merged into this node. For any call stack, there can only be one such node per exceptional method.
•  [current exceptional run]
  If an invocation was in progress while the call tree view was transmitted to the JProfiler GUI, it was not yet known whether the invocation was exceptionally slow or not. The "current exceptional run" shows the separately maintained tree for the current invocation. After the invocation completes, it will either be maintained as a separate "exceptional run" node or be merged into the "merged exceptional runs" node.

Like for call tree splitting by probes and split methods, an exceptional method node has a Merge Splitting Level action in the context menu that lets you merge and unmerge all invocations on the fly.