From a0beef4ff21e7ed77264bfa5ff33ce21d3348deb Mon Sep 17 00:00:00 2001 From: compudj Date: Sun, 28 Aug 2005 16:26:43 +0000 Subject: [PATCH] detailed event list redesign git-svn-id: http://ltt.polymtl.ca/svn@1086 04897980-b3bd-0310-b5e0-8ef037075253 --- .../guidetailed-event-list-redesign.txt | 136 ++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 ltt/branches/poly/doc/developer/guidetailed-event-list-redesign.txt diff --git a/ltt/branches/poly/doc/developer/guidetailed-event-list-redesign.txt b/ltt/branches/poly/doc/developer/guidetailed-event-list-redesign.txt new file mode 100644 index 00000000..ac46090e --- /dev/null +++ b/ltt/branches/poly/doc/developer/guidetailed-event-list-redesign.txt @@ -0,0 +1,136 @@ + +Redesign of the GUI detailed event list + +Mathieu Desnoyers 08/2005 + +The basic problem about this list is that it uses the number of events, not the +time, as a vertical axis (for the Y axis scrollbar). + +Seeking in the traces is done by time. We have no clue of the number of events +between two times without doing preparsing. + +If we want to fully reuse textDump, it's bettwer if we depend upon state +computation. It would be good to make the viewer work with this information +missing though. + +textDump's print_field should be put in a lttv/lttv core file, so we can use it +as is in the detailed event list module without depending upon batchAnalysis. + + +* With preparsing only : + +The problem then becomes simpler : + +We can precompute the event number while doing state computation and save it +periodically with saved states. We can then use the event number in the trace +as scrollbar value, which, when scrolled, would result into a search in the +saved states by event number. + +How much time would it take to seek back to the wanted position from the last +saved state ? + +compudj@dijkstra:~/local/bin$ ./lttv -m batchtest -1 -2 -t +/home/compudj/traces/200MB +** Message: Processing trace while counting events (12447572 events in 14.0173 +seconds) +** Message: Processing trace while updating state (9.46535 seconds) + +9.46535 s / 12447572 events * 50000 events = 0.038 s + +38 ms latency shouldn't be too noticeable by a user when scrolling. + +(note : counting events batchtest does also verify time flow integrity and get +the position for each event (not optimal), that's why it takes 14s) + +As an optimisation, we could use a backing text buffer (an array of strings), +where we would save the 50000 computed events between two consecutive saved +states. + +Memory required : 50000 * 20 bytes/event = 1MB + +Which seems ok, but costy. In would be better, in fact, not to depend on the +saved states interval for such a value : we could keep a 1000 events array, for +instance (for 20KB cost, which is really better). + +The backing text buffer would, by itself, make sure it has a sufficient +number of events so a scroll up/down of one page would be responded directly. +That imply that a scroll up/down would first update the shown fields, and only +afterward make the backing buffer resync its events in the background. In the +case where the events were not directly available, it would have to update the +buffer in the foreground and only then show the requested events. + + + + +* If we want the viewer to be able to show information without preparsing : + +This is the hardest the problem could get. We have to seek by time (even the +scrollbar must seek by time), but increment/decrement event by event when using +the scrollbar up/down, page up/page down. Let's call them "far scroll" and "near +scroll", respectively. + +A far scroll must resync the trace to the time requested by the scrollbar value. + +A near scroll must sync the trace to a time that is prior to the requested +event, show the events requested, and then sync the scrollbar value (without +event updating) to the shown event time. + +* seek n events backward + +We have no information about how far back we must request events in the trace : + +The algorithm would look like : + +seek_n_events_backward(current time, current position, time_offset, filter) +Returns : a TracesetPosition + - If the current time < beginning of trace, is means we cannot get any more + events, inform the requester that a list of less than n events is ready. + - Else, request a read to a the time_offset backward, calling the + per event hook, and calling the after_traceset hook when finished. The end + position would be the position of the current first event. + +per_event_hook + - if filter returns true + - Append the traceset position to a list of maximum size n. Remove the first + entries. + +after_traceset_hook + - if the list has a size less than n, invoke a seek_n_events_backward + subsequent iteration, for completing the list. The new time_offset is the + last time_offset used multiplied by 2. (can be done by tail recursion (if we + want to split this operation in multiple segments) or by an iterative + algorithm (seek_n_events_backward would be a while() calling its own + process_traceset_middle()). + - if the list a a size of n, it's complete : call the viewer get_print_events + hook. + + +* seek n events forward + +seek_n_events_forward(current position, filter) + - Simple : seek to the current position, request read of trace calling an + event counting hook (starts at 0). + +event_counting_hook + - if filter returns true + - increment event count. + - if event count > requested count, inform that the current position if the + wanted position. Return TRUE, so the read will stop. + + +* Printing events + +get_print_events + - seek to the position at the beginning of the list. End position is the + current one (not in the list! the one currently shown). Call a events + request between this positions, printing the fields to strings shown in the + viewer. + + + +seek_n_events backward and forward seems to be interesting algorithms that +should be implemented in the tracecontext library. With those helpers, it would +become simpler to implement a detailed event list not depending on state +computation. + + -- 2.34.1