Narrowing focus on the profiling data: Filtering

When you profile your application, it's likely you'll receive a lot of data, from all over your application: the longer the profiling session, the more data is collected. However the more data in a snapshot, the more information you have to wade through to focus on the real problem areas in your application.

To overcome this, ORM Profiler has a fine-grained filtering system which allows you to filter on the message stream before the messages are stored in the snapshot. This way, you can profile your application, perform activity with the application, e.g. open a couple of forms, save some data, and in the profiler you only see the messages which passed the filters specified.

Any message filtered out is not added to the snapshot. If you want to look at the data filtered out, you have to profile your application again. By default no filters are enabled, so all messages are accepted. Filtering is recommended when you want to look at a specific part of your application which shows performance problems or which is a suspect of being sub-optimal.

This way you can follow the Isolate, Analyze, Interpret and Fix pattern to quickly find the real cause of performance problems in your database using applications.

Setting filters and filter parameters

To specify filters in the UI, click on the Filter Settings button on the Home tab, which will allow you to edit the actual filter settings known to the system. Many filters are configurable with arguments. Filters have to be set up prior to starting a profiling session: a new profiling session will use the actual filter settings for the new snapshot.

Available filters

The following filters are available in ORM Profiler.

Filter on Application name. Filters the received data on application name. Filter uses a case-insensitive test whether one or more of the fragments specified are present in the application names in the received data. Application names are specified with the ORM Profiler's Interceptor initialization method.
Filter on Database type. Filters the received data on database type.
Filter on Connection string. Filters the received data on the related connection strings. Filter uses a case-sensitive 'contains' test whether one or more of the fragments specified are present in the connection strings in the received data.
Filter on Query text. Filters the received data on the related SQL query text. Filter uses a case-sensitive 'contains' test whether one or more of the fragments specified are present in the SQL query strings in the received data.
Filter on Database object name. Filters the received data on the related database object names. Filter uses a case-sensitive test whether one or more of the fragments specified are present in the SQL query strings in the received data.
Filter on Command type. Filters the received data on the command types of the queries.
Filter on Command execution type. Filters the received data on the command execution type of the queries.
Filter on Stack trace fragment (all). Filters the received data on the stack traces of the calls related to the various data elements. Filter uses a case-sensitive test whether one or more of the fragments specified are found as the filename, declaring type or method name in any of the stack trace frames associated with the various elements.
Filter on Stack trace fragment (Filename). Filters the received data on the stack traces of the calls related to the various data elements. Filter uses a case-sensitive test whether the specified name is found as the filename in any of the stack trace frames associated with the various elements.
Filter on Stack trace fragment (Declaring type name). Filters the received data on the stack traces of the calls related to the various data elements. Filter uses a case-sensitive test whether the specified name is found as the method name in any of the stack trace frames associated with the various elements.