- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- 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
Much useful profiling information is available in the live views when the profiler is connected to a profiled application. However, to use all analysis capabilities the profiler provides, a snapshot should be captured, i.e. the collected profiling data written to a file.
When you capture snapshot of the remove application, profiler will offer to download the captured snapshot from the remote computer. You will able to enable compression to save the network traffic.
Snapshots can also be captured automatically:
Using startup options:
- On high memory usage with help triggers
- Using Profiler .NET API
- Using Profiler HTTP API
Memory vs performance snapshots
Memory snapshots contain the memory state of the profiled application at the moment it was captured. It contains information about all loaded classes, about all existing objects, and about references between objects.
The heap is necessary for comprehensive memory profiling. If you need that information, capture memory snapshot:
Performance snapshot will contain all the same information as a memory snapshot except for the detail on individual objects in the heap.
Note: snapshots captured on exit are always performance snapshots due to a technical reason: capturing a memory snapshot requires to force garbage collection which is not possible when the CLR is being shut down.