Time Measurements in Different CPU Views

   


1. Wall clock time and CPU time

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

2. 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 that waiting to perform a task. Most of the time would then be 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.

3. 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 inherent time of a node. The inherent time is defined as the total time of 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 inherent time. If you change your method call recording filters, the inherent times in the call tree can change.

4. Times in the hotspots view

While the call tree view shows all call stacks in your application, the hotspot 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 hotspots view do not have to match. The hotspot view shows the inherent time rather than the total time. In addition, the hotspot view offers the option to include calls to filtered classes into the inherent time. Please see the article on hotspots and filters for a thorough discussion of this topic.

When you open a hotspot 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 hotspot time at each node.

5. 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 hotspots 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.