Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 326822

Summary: [TMF] Event filtering
Product: z_Archived Reporter: Francois Chouinard <fchouinard>
Component: LinuxToolsAssignee: Francois Chouinard <fchouinard>
Status: CLOSED WONTFIX QA Contact: Francois Chouinard <fchouinard>
Severity: enhancement    
Priority: P3 CC: alexmonthy, malaperle, patrick.tasse, thomas_gatterweh
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:

Description Francois Chouinard CLA 2010-10-01 17:24:17 EDT 
The TmfDataRequest class is complemented with a new TmfFilteringDataRequest class that includes the additional filter criteria object. It is used with a new TmfExperiment#processRequest method that takes a TmfFilteringDataRequest object as parameter. The events returned by this request all match the filter criteria object as tested by the TmfTrace#testEvent method as described above.

A new experiment class is derived from TmfExperiment, TmfFilteredExperiment, that accepts a filter criteria object in the constructor. It provides all standard TmfExperiment interfaces, but returns only event data that match the filter criteria.

In other words, the TmfFilteringDataRequest is typically used in find/search scenarios, whereas the TmfFilteredExperiment is typically used where existing components like views shall be fed with filtered event data.

Note:
-----
- I would like to suggest that it might be more interesting to keep ITmfTrace simple and move the filtering stuff to its own API (e.g. ITmfEventFilter). Then the filter could be added to the TmfData/EventRequest constructors instead of extending TmfDataRequest.

- I am a little bit confused about the meaning of a filtered experiment. Do you mean to have multiple instances of an experiment using various filters? I am a bit curious as this is not one of my use cases.
Comment 1 Thomas Gatterweh CLA 2010-10-04 09:09:57 EDT 
Regarding filtered experiments: When you filter at TmfDataRequest level, the experiment *output* is filtered. When you create a filtered experiment, you move the filter at experiment *input* level. In a filtered experiment, the internal event indexing works with already filtered data, and thus event index 'n' represents the n-th *matching* event.

For example, when you issue a data request for events 1000-1099 to an unfiltered experiment, but using a filter at TmfDataRequest level, it will search the event 1000-1099 and return all matching events. That can be anything from 0 to 100 events. This is what you would expect, e.g., in a search results view.

Contrary, when you issue the same request to the filtered experiment, you will get 100 events matching the filter, starting with the 1000th match. This is what you would need, e.g., in an event view displaying filtered events to refresh lines 1000-1099.

> Do you mean to have multiple instances of an experiment using various filters?
Yes, for certain purposes we use multiple instances of experiments with different filters or even reduced number of traces.
Comment 2 Francois Chouinard CLA 2010-10-04 10:11:33 EDT 
I see your point and it addresses a shortcoming. +1.
Comment 3 Patrick Tasse CLA 2013-05-23 17:45:18 EDT 
*** Bug 302488 has been marked as a duplicate of this bug. ***
Comment 4 Patrick Tasse CLA 2013-05-23 17:46:23 EDT 
Removing blocking dependency on bug 301615.
Comment 5 Alexandre Montplaisir CLA 2014-10-15 17:11:36 EDT 
From a performance point of view, there is not much difference between requesting "one event out of two" or "every single event" from a trace. The parser often has to read and decode all events to decide if they match a filter or not.

Additionally, if many components request the same time range from a trace ("time range" usually being "gimme the whole thing"), those requests can be coalesced, effectively reading the trace only once. Adding a filtering element at that level could slow down the event throughput, even for components who didn't want any filtering.

Finally, with the analysis modules that were added relatively recently, each module can now do its own filtering and indexing in any way it desires. So it was deemed better/simpler if the core event request could only return "all the events", and the filtering was done independently afterwards by each analysis.