- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- IDE integration
- Profile .NET executable
- Profile ASP.NET application IIS
- Profile all .NET processes that will start
- Attach profiler to a running application
- Profile remote applications
- Profiling in Docker container
- Manually enable profiling of local applications
- Startup options
- Profiling overhead: how to reduce or avoid
- Profiling troubleshooting
- Connect to profiled application
- Capturing snapshots
- Solving performance problems
- CPU profiling
- Memory profiling
- Garbage collection
- Exception profiling
- Probes: monitor higher level events
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- Time measurement (CPU time, wall time)
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler API
- Profiler HTTP API
- Command line tool to control profiling
Profiling overhead: how to reduce or avoid
The profiler may add some overhead to the performance of applications you profile. This overhead may vary from virtually zero to significant, depending on the conditions described below.
Overhead of running an application with the profiler
The overhead depends on the profiling capabilities specified on the Welcome screen.
Enabling CPU tracing and/or object allocation recording adds overhead which is, however, acceptable for most applications.
If CPU tracing and object allocation recording are disabled, the overhead is virtually zero.
Overhead when measuring is performed
When CPU profiling or object allocation recording are running, the profiler adds extra overhead. After measuring is done and turned off, overhead should decrease to the initial level described above.
Tracing overhead is greater than sampling overhead.
Object allocation recording overhead depends on the number of recorded objects. To reduce the overhead, record fewer objects with the help of the "Record each..." constraints.
During the capture, the profiled application is paused. The time it takes to capture a memory snapshot depends on the heap size. Capturing memory snapshots of huge heaps takes more time because of the intensive use of the system swap file (if little free physical memory is available).