Description Francois Chouinard 2010-10-01 17:23:12 EDT

The indexing operation of TmfTrace objects is changed to use the new skip feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=326820). As such, indexing performance is vastly improved, and indexing of fixed size event streams is now very fast.

Some methods to control indexing are added. Beside the existing method indexStream() the new methods reindexStream(), isIndexingStream() and stopIndexingStream() are added.

The indexing operation of TmfExperiment objects is completely rewritten to improve performance. A heuristic is used to employ the new skip feature as much as possible, even when multiple traces are in the experiment.

An EventIterator class is added that provides significantly better performance than the getNextEvent() method. When the getNextEvent() method had an effort of o(n) where n is the number of traces in the experiment, the new class has an effort of o(1) – in the case when multiple traces in the
experiment do not overlap in time – to o(log n) – in the case when multiple traces in the experiment overlap in time.

The getNextEvent(), positionTraces() and processDataRequest() methods are changed to use the new EventIterator class.

Note1
-----
The trace/experiment indexing strategy was modified since to take advantage of the fact that the experiment has to read the traces to build its own index: the indexes (trace and experiment) are built as the events are read by getNextEvent(). Therefore, indexing a experiment (and its traces) boils down to processing a request to read the whole experiment. This was done to prepare the ground for trace streaming: as new incoming events are read, the index is updated on-the-fly.

Nonetheless, it should be fairly straightforward to adjust the indexing functions to use the much more efficient skipEvent(). Since requests can be cancelled and queried (for their current state), the complementary functions shouldn't be a problem either.

Note 2
------
I was thinking of changing the ITmfTrace API and move getNextEvent() to ITmfContext which would now act as an iterator (I guess I'm finally graduating from C to Java :-). It would work a bit like this:

ITmfContext myContext = myTrace.seekEvent(<some location criteria>, myRequest.getEventFilter());
while (!myContext.isCompleted() {
    event = myContext.getNextEvent();
}

I was pleasantly surprised when I saw that you introduced an EventIterator in the TmfExperiment(s)... Not exactly the same semantics, but a very similar concept that, I believe, would deserve to become a standalone TMF class.