Using Different Kinds of Timers
By default, the results only display the elapsed, or absolute, time spent in profiled
methods. Note, though, that the Profiler always attempts to give you both the absolute
and thread CPU time for your whole profiled call subgraph. This time is measured
as an interval between the time the given thread entered the root method and
the time that it exited this method, minus the estimated time spent in the injected
instrumentation code. Absolute time for the whole subgraph is always shown.
Thread CPU time, however, is shown only if thread CPU time measuring at method
level is active (see below), or if at the moment when you request the data,
the given execution thread is not within the call subgraph. Otherwise, the Profiler
says that thread CPU time is unavailable. This is a purely technical limitation,
which may be eliminated in future.
If you profile a multi-threaded application, it often makes sense to measure
thread CPU time for profiled methods in addition to, or instead of, the absolute
time. You can choose between measuring only absolute, only thread
CPU, or both times. Note that if you turn on both timers, the profiling overhead
will increase, since the instrumentation that we inject into the target application
code will have to make two timer calls instead of one every time an application
method is entered or exited. Note also that on Windows and Linux, the resolution
of the thread CPU timer is very low - about 10 ms, compared to a fraction of
a microsecond for the absolute timer. Thus it makes little sense to use the
thread CPU timer for individual methods on these platforms, at least if these
methods tend to run for less than, say, 50..100 ms. On Solaris, the situation
is considerably better - the resolution of the thread CPU timer on this OS is
about 1 ms, and the call to this timer also takes much fewer CPU cycles than
on Windows (on the order of 10 times fewer).
See also
