Home > Profiling Tasks > Custom Profiling
CPU Profiling settings
In the Custom Profiling mode, you have complete control over all of the internal
profiling settings available. When you choose CPU profiling, you can
choose between profiling the entire application, part of the
application, or application startup.
Choosing the CPU Profiling option brings up the following settings dialog box (switched to Part of Application):
The dialog box allows you to further refine the following profiling configuration:
-
Methods Tracking: full (Exact Call Tree and Timing)
or sampled (Exact Call Tree, Sampled Timing). During CPU profiling, Profiler
injects a "method entry" call at the beginning of each profiled
method, and a "method exit" call before each return.
In the full instrumentation mode, each "method entry" and "method
exit" call generates a timestamp, and the time spent in the method
is calculated as a difference between these timestamps. In sampled instrumentation
mode, timestamps are not taken on every "method entry"/"method
exit" call, but only at those that fall approximately at end of each
sampling period that you specify.
For details, see
Full Instrumentation vs. Sampled Instrumentation.
-
Instrument new threads started within root methods execution. When checked, this
option makes Profiler instrument the code for any thread started after the
application entered the root instrumentation method (see
Profiling Single-Threaded and Multi-Threaded Applications).
For the Entire Application mode this option is set by default and the control is hidden.
-
Use Thread CPU Timer. The timestamps of method entry/exit events
can be taken using different kinds of OS timers. By default, absolute timer
is used to measure absolute, or wall clock time. Thread CPU timer measures
only the time spent executing the given thread. Essentially, the OS suspends this
timer every time the CPU stops executing the code on behalf of the given
thread, and resumes it every time execution switches back to this thread. This
option is available only for the Solaris OS.
For details, see Using Different Kinds of Timers.
-
Instrumentation: filter. You can limit the number of classes that
are instrumented and profiled by specifying an instrumentation filter.
You can define more profiling settings in the Advanced tab (switched to Part of Application):
Available options are:
-
Limit number of profiled threads. You can limit the number of
threads that are profiled. Every time a thread that has not been previously
registered enters the instrumented code, this counter is decremented. When
it reaches zero, registration of new threads is stopped. Profiling data
is collected only for the registered threads. The counter is reset to the
value specified above every time you invoke the Profile > Reset Collected
Results ( 
).
For details, see Profiling
Single-Threaded and Multi-Threaded Applications.
-
Instrumentation: scheme. By selecting an instrumentation scheme,
you can limit the number of instrumented methods. Usually, it is best if
the number of instrumented methods and the number of methods actually called
by the application when it is profiled are the same or very close. The
default scheme for Part of Application is "Lazy". Usually it is most appropriate when you
want to profile a subset of the application code (for example, just one
or more servlets running on top of an application server) because it
results in the smallest number of instrumented methods. However, total instrumentation
may be more appropriate if you want to profile application startup, or an
entire application such as a short-running command line utility. For the Entire
Application mode "Total" instrumentation is default value and the control is hidden.
For details, see
Instrumentation Schemes.
-
Instrument/not instrument various special Java methods. When "Instrument
Method.invoke()" is checked, all calls
done using Java Reflection (i.e. the java.lang.reflect.Method.invoke()
call) are followed and instrumented. Otherwise, such calls are not followed.
The other two options specify whether Profiler should instrument methods that
either get/set object fields, and methods that don't contain any executable
code. Typically it does not make sense to instrument these methods, since
the HotSpot JVM optimizes them very efficiently and normally their execution
time is negligible. When instrumented, however, they may contribute to the
profiling overhead noticeably. Check these boxes only if you want to find
out whether, or how many times, some of these methods are called.
See also
