Community
Participate
Working Groups
build: 20020109 Note: To notice the slow performance of marker filters turn on filters, load a project with many errors, and click around on different resources. If you have task filering turned on (either to selected resource or selected resource and its children), I believe that too many calls to Resource.findMarkers are being made. Each time the resource selection changes, 6 separate calls are being made. Here are the details: - find markers of type problemmarker for Foo.java - find markers of type taskmarker for Foo.java - find markers of type problemmarker for Foo.java - find markers of type taskmarker for Foo.java - find markers of type problemmarker for the workspace root - find markers of type taskmarker for the workspace root In the above, the first 2 calls are made to determine the actual markers which are to be displayed. I would presume that there is one call per "task list marker type hierarchy root". (e.g. the task list only displays problems, tasks, and their subtypes) The second and third pairings of calls are made to determine the numbers which should be displayed in the status bar (4 of 27, 1 of 12, etc) with the first pair calculating the number of markers that we have and the second pair calculating the total number of markers in the workspace. Note that the two calls on the workspace root causes every resource in the workspace to be visited twice. The more resources in the workspace and the higher up someone clicks (e.g. on the project rather than on a particular java file), the slower these operations will be. Some notes/comments: - can the number of markers we have be cached from the first 2 calls where we get the actual markers themselves? we're returning an array so we should have the length. - the task list is being updated because the focus changed in the Navigator (I believe). is there a scenerio where a change in focus in the Navigator will add/remove markers from the workspace and its resources? If not, then the total number of markers in the workspace can be cached and re-used. If so, then won't the marker additions/removals appear in the resource deltas and can be processed from there? (its probably more complicated than this, but its just a comment to get the thought process going) - if both problemmarker and taskmarker inherited from a new marker type (tasklist marker?) then a single call could be made for each pair as it would be the root of all marker types to be shown in the task list view. Note that this might be too much of a change and it would also require changes in Core's plugin.xml as they define the problem and task markers. Comments?
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.
*** This bug has been marked as a duplicate of 11164 ***
