Time Measurements in Different CPU Views


Wall clock time and CPU time

When the duration of a method call is measured, there are two different possibilities to measure it:

Thread statuses

The notion of time measurement must be refined further, since not all times are equally interesting. Imagine a server application with a pool of threads waiting to perform a task. Most of the time would then be spent in the method that keeps the threads waiting while the actual task will only get a small part of the overall time and will be hard to spot. The necessary refinement is done with the concept of thread status. There are 4 different thread statuses in JProfiler:

When looking for performance bottlenecks, you're mostly interested in the "Runnable" thread state although it's always a good idea to have a look at the "Net I/O" and "Blocking" thread states in order to check if the network or synchronization issues are reducing the performance of your application.

Times in the call tree

Nodes in the call tree (methods, classes, packages or Java EE components, depending on the selected aggregation level) are sorted by total time. This is the sum of all execution times of this node on the particular call path as given by the ancestor nodes. Only threads in the current thread selection are considered and only measurements with the currently selected thread status are shown.

Optionally, the call tree offers the possibility to show the self time of a node. The self time is defined as the total time of a method minus the time of its child nodes. Since child nodes can only be in unfiltered classes, calls into filtered classes go into the self time. If you change your method call recording filters, the self times in the call tree can change.

Times in the hot spots view

While the call tree view shows all call stacks in your application, the hot spots view shows the methods that take most of the time. Each method can potentially be called through many different call stacks, so the invocation counts in the call tree and the hot spots view do not have to match. The hot spots view shows the self time rather than the total time. In addition, the hot spots view offers the option to include calls to filtered classes into the self time. Please see the article on hot spots and filters for a thorough discussion of this topic.

When you open a hot spot node, you see a reverse call tree. However, the times that are displayed in those backtraces do not have the same meaning as those in the call tree, since they do not express a time measurement for the corresponding node. Rather, the time displayed at each node indicates how much time that particular call tree contributes to the hot spot. If there is only one backtrace, you will see the hot spot time at each node.

Times in the call graph

The times that are shown for nodes (methods, classes, packages or Java EE components, depending on the selected aggregation level) in the call graph are the same as those in the hot spots view. The times that are associated with the incoming arrows are the same as those in the first level of the hot spot backtrace, since they show all calling nodes and the cumulated duration of their calls. The time on the outgoing arrows is a measurement that cannot be found in the call tree. It shows the cumulated duration of calls from this node, while the call tree shows the cumulated duration of calls from the current call stack.