When the profiler is connected to the profiled application, the toolbar contains the following CPU profiling controls:
To begin obtaining profiling results, start CPU measuring when your application requires it.
When sampling is used, the profiler periodically queries stacks of running threads to estimate the slowest parts of the code. No method invocation counts are available, only CPU time.
Sampling is typically the best option when your goal is to locate and discover performance bottlenecks. With sampling, the profiler adds virtually no overhead to the profiled application.
However, the probes for the high-level statistics, if enabled, may impose additional overhead.
You can configure some CPU sampling aspects with CPU sampling settings.
When tracing is used, the profiler instruments the bytecode of the profiled application for recording thread CPU time spent inside each profiled method. Both times and invocation counts are available.
Although tracing provides more information, it has its drawbacks. First, it may noticeably slow down the profiled application, because the profiler executes special code on each enter to and exit from the methods being profiled. The greater the number of method invocations in the profiled application, the lower its speed when tracing is turned on.
The second drawback is that, since this mode affects the execution speed of the profiled application, the CPU times recorded in this mode may be less adequate than times recorded with sampling. Please use this mode only if you really need method invocation counts.
To control profiling overhead and accuracy of the results use CPU tracing settings.
Also, the probes for the high-level statistics, if enabled, may impose additional overhead.
Call counting is the most lightweight CPU profiling mode.
It's a simple tool for identifying potential performance problems caused by suboptimal algorithms. The approach is based on assumption that method(s) with a big number of invocations may indicate a performance problem.
Call counting is specially designed to have minimal possible, almost zero overhead:
Use call counting to initially detect possible problems: thanks to its low overhead you may do this even in production.
Further investigation may involve using CPU tracing or sampling to get comprehensive profiling results including times and stack traces (call tree).
Please note that CPU tracing and call counting are based on bytecode instrumentation.
If the startup options
disableall are specified,
it will be disabled, making CPU sampling the only available mode.
When CPU profiling is started, the results are immediately available in "Call tree" (with threads merged) and "Method list" tabs.
In case of CPU tracing, both method times and invocation counts are shown. In case of CPU sampling, only times are shown.
The live view provides only basic information. To perform comprehensive analysis, capture performance snapshot, open it and use the full featured CPU view.
When the task you intended to profile has finished (or has performed for a sufficient amount of time), capture a performance snapshot with all the recorded information.
When this is done from the profiler UI, you can open the results for immediate analysis.
Further topics in this section describe the profiler's UI for analyzing CPU profiling results.