- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Start profiling
- Capturing snapshots
- Solving performance problems
- CPU profiling
- Threads
- 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)
- Filters
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler API
- Profiler HTTP API
- Command line tool to control profiling
- Settings
Filters
Filters help you to ignore methods and instances of classes which you are not interested in, such as standard classes, libraries, framework internals, application server core classes etc., so you can more easily focus on own classes of the profiled application.
Filters are applied in the profiler UI
While reviewing profiling results in a snapshot or in live views, you can use different filters or use none at all. In other words, you do not need to start a new profiling session to start or stop using filters. Views are automatically updated when filter settings are changed.
Filters reduce the depth of call trees and length of stack traces, by skipping successive calls of methods from filtered classes, so you can more easily see the methods of the profiled application.
Filters are applied to views where method call stacks are shown, as well as to hot spot and method list views.
Non-filtered methods are marked with a filled arrow .
Filtered methods have an outlined arrow
:

Some automatic inspections use filter settings to focus on potential problems in own code of profiled application.
Switch between applying and not applying filters in the profiler UI
A quick way to turn applying the configured filters on/off is to use Settings | Apply Filters.
Configuring filters
Use Settings | Filters... in the main menu to configure filters.

Each filter is specified as a list of class or method patterns to be filtered, one pattern per line.
To filter all methods in given class(es), use this format:
<fully qualified class name>
To filter particular methods in given class(es), use this format:
<fully qualified class name> : <method name> ( <comma-separated parameter types> )
Wildcards ('*') are accepted.
Examples
Foo.Bar.MyClass
- filter all methods of given class
Foo.Bar.MyClass:*(*)
- same as above
Bar.*
- filter methods in all matching classes
Bar.* : print*(*)
- filter all methods from Bar.* with name starting with 'print' and any number of parameters
* : ToString()
- filter ToString() in all classes
Foo.Bar.* : .ctor(System.Int32)
- filter constructors of classes in Foo.Bar.* with given signature
To specify classes or methods which must not be filtered, prepend the pattern with '+'.
The following example filters classes in namespaces 'Foo' and 'Bar' and their nested namespaces, but not in 'Bar.MyNamespace' and nested namespaces:
Foo.*
Bar.*
+Bar.MyNamespace.*