- System requirements
- Profiler architecture
- Profiler installation
- Running the profiler
- Profiler activation
- Welcome screen
- Start profiling
- Profiling overhead: how to reduce or avoid
- Solving performance problems
- CPU profiling
- CPU and wall times when profiling .NET applications
- CPU profiling modes
- CPU usage estimation
- CPU sampling
- CPU sampling settings
- CPU tracing
- CPU tracing settings
- CPU tab
- What-if: an ability to ignore particular methods or focus on particular methods only
- Memory profiling
- Garbage collection
- Exception profiling
- Performance charts
- Probes: monitor higher level events
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Automatic deobfuscation
- Summary, automatic deobfuscation
- Profiler command line
- Command line tool to control profiling
- Export of profiling results to external formats
- Profiler API
- Profiler HTTP API
CPU tracing settings
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 no-entry sign
- 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:
You can specify a custom settings file for a particular application by using the startup option