Description John Arthorne 2001-10-10 22:43:39 EDT

While profiling typical edit/build iterations in Eclipse, I noticed that updating the task list
status line message takes a lot of time (about 5.5% of the total time), even in the case where
there are no tasks in the task list at all! This is because it doesn't make use of the marker
deltas, but just asks Core to compute the complete set of markers for the given selection, depth, etc.
This information is already available, because the marker objects are in the table viewer.  It just has
to grab the set of markers currently visible in the table, and generate the appropriate summary message.
Even better, the task list content provider could incrementally update the summary information based on the
provided marker deltas.

NOTES:

JohnA (9/24/2001 3:20:02 PM)
	Another drawback of the current approach is that when the task list is first
	opened, fetching the markers twice causes two tree walks, that need to allocate
	lots of objects.  In an extreme case I was profiling, in a workbench with the entire
	eclipse source (11,000 files), opening the task list allocated 44,000 objects to fetch
	the markers twice.  The fourfold increase is due to the fact that it fetches two
	different kinds of markers each time (tasks and errors).