Summary: | Performance: Task list, filtering, and findMarkers | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | DJ Houghton <dj.houghton> |
Component: | Resources | Assignee: | DJ Houghton <dj.houghton> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | Keywords: | performance |
Version: | 2.0 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | other | ||
Whiteboard: |
Description
DJ Houghton
2002-01-10 17:23:17 EST
Your analysis makes sense. As you suggest, the task list could cache the total number of markers it presents and update it incrementally. This would make a big difference. Adding a common supertype for problems and tasks would be possible, but is not a good split since Core would have to define it, but it shouldn't know anything about the task list. It might be better to have the task list retrieve all markers then filter them by type, assuming that most are tasks or problems. However, checking the types of markers is also slow. Could probably do some cool caching here, e.g. remember that Java problem is a problem type. It would be good if this was in Core rather than the task list. We'd still have to retrieve the type. It would also be a big performance improvement across the board when dealing with markers if Core did not have to traverse all resources in order to discover which ones had markers. In the original marker implementation, the markers had their own sparse tree representation in the workspace, parallel to the resource tree, but with nodes only for those resources with markers (and their parents). With this representation, if there were no markers, you could discover this in O (1) time. The time to retrieve markers was proportional to the number of markers retrieved, not the number of resources. The above improvements have been made to the task list. Moving to Core for the suggested marker performance improvements. If the ResourceInfo contained a bit indicating whether any child resources had markers, findMarkers could be made much faster: proportional to the number of markers rather than the number of resources. |