- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Running applications with the profiler
- Connect to profiled application
- Troubleshoot connection problems
- Solving performance problems
- CPU profiling
- CPU usage estimation
- Asynchronous sampling
- Call counting
- CPU tab
- What-if: an ability to ignore particular methods or focus on particular methods only
- Comparing performance snapshots
- Sampling settings
- Tracing settings
- Deadlock detector
- Memory profiling
- Garbage collection
- Monitor profiling
- Exception profiling
- Probes: monitor events of various kinds
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- IDE integration
- Time measurement (CPU time, wall time)
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler Java API
- Profiler HTTP API
- Command line tool to control profiling
- FAQ: How to profile in my scenario?
CPU tracing settings allow to customize some aspects of CPU tracing.
CPU sampling settings are specified separately, as described here.
When the settings are applied
The settings are applied each time you start CPU tracing. This means you can change the settings without restarting the profiled application.
Configuring the settings
To configure CPU tracing settings use Settings | CPU Tracing... in the main menu.
The settings are also accessible via a link in the CPU profiling toolbar popup:
The following dialog appears:
Specify whether CPU or wall time will be measured for profiled methods by using the
The default configuration for CPU tracing is to measure wall time (
time=wall). This reduces CPU tracing overhead and increases accuracy of the results because the wall time timers are faster and more accurate than CPU time timers.
To measure CPU time instead, specify
When starting tracing from the profiler UI, choose the option via Use Preconfigured Settings... or manually edit the property value.
Adaptive tracing mode
Adaptive tracing mode automatically reduces profiling overhead by skipping short running methods with big number of invocations. Such methods usually cause the most significant profiling overhead, and their exclusion results in both faster tracing and more realistic results. The decision to exclude particular method is made basing on the statistics collected during the current tracing session.
Excluding a method means that there will be no exact results for it (time, invocation count), but for its callers only. Due to reduced overhead, its caller method time will be more adequate.
The benefit of adaptive tracing is that it does not require human interaction and works with any application, eliminating the need to explicitly specify filters for particular application if default filters do not fit well. However, please note that the adaptive tracing needs some time to warm up, i.e. to collect statistics on which methods deserve to be excluded.
To enable adaptive tracing specify
To disable adaptive tracing specify
Methods excluded by adaptive tracing are specially presented in UI:
- the methods are indicated with the icon
- because the actual time and invocation count for the methods is most likely bigger than the amount measured by the moment when the methods have been excluded from tracing, the time and invocation count values are prepended with the greater-or-equal sign, the average and own time values - with the approximately-equal sign:
The configuration file
The settings are stored in the file
where user home corresponds to the account under which a profiled application is launched.
This file is automatically updated in your user home directory when you apply changes in the UI (see above). You can also edit it manually.
The settings file is read and applied when CPU tracing is started with:
- the command line tool
You can specify a custom settings file for a particular application by using the startup option