Products
 
 
 
Fully featured low overhead profiler for Java EE
and Java SE platforms.
Easy to use performance and memory profiler for .NET framework.
Supports ASP.NET, Silverlight, .NET Windows services and more.
previous      content      next
Filters

Filters help you to ignore methods and instances of classes which you are not interested in, such as standard Java classes, libraries, framework internals, application server core classes etc., so you can more easily focus on own classes of the profiled application.

Applying filters in profiled application runtime

Limiting collected information to certain classes only reduces its value for further analysis, as some important detail potentially can be missed.

The only reason not to collect all available information is to reduce profiling overhead which otherwise would be significant.

That is why filters are applied in runtime only to:

  • CPU tracing results
  • the stack traces of events recorded with probes and triggers when CPU tracing is running, to ensure the probe and trigger results are consistent with CPU tracing results, as well as to reduce overhead

No other profiling mode which collects stack trace related information applies filters in runtime.

Applying filters in the profiler UI

While reviewing a snapshot, 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 (of course, except for CPU tracing results which need to be collected anew - see above.)

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

There is a quick way to turn applying the configured filters on/off:

  • with a new main menu item Settings | Collapse Filtered Calls
  • "Filters..." hyperlink in the Legend when working with a snapshot

Configuring filters

Select 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
com.foo.* : <init>(int, String) - filter constructors of classes in com.foo.* with given signature

To specify classes or methods which must not be filtered, prepend the pattern with '+'.

Example: filter classes in packages 'foo' and 'bar' (with subpackages), but not in package 'bar.myclasses' (with subpackages):

foo.*
bar.*
+bar.myclasses.*

previous      content      next