Community
Participate
Working Groups
ClassFileMarkerAnnotationModel.visit is very much less than optimal if fMarkerResource is set. It traverses the entire delta only looking for a particular resource! I don't understand when fMarkerResource is set and when it is not but in the case I saw, it was set to be a particular project resource which was not even in the list of resources which changed in the large delta I was processing. The net result of this was that the listener traversed the entire delta (~1500 resources) checking at each node to see if the node was equal to fMarkerResource. Since the listener knows that it is only interested in that one resource, it should just take the delta and look in it to see if the resource in question is there. The current IResourceDelta api is not optimal for doing this but it certainly can be done and would be very much more efficient than the current approach. We will look at adding the required API but this late in the game I would not hope for too much. NOTES: JBL (6/1/2001 11:47:09 AM) ClassFileMarkerAnnotationModel is JUI. Moving to ITPJUI. KUM (8/6/2001 4:41:57 PM) Sent mail to JMA regarding expected core support.
PRODUCT VERSION: 116
Should make use of public IResourceDelta findMember(IPath path);
As a test case, I make a search with lots of results (all references to IJavaElement) and see how long the update of the marker takes. I'd like to see 7597 fixed to be able to verify this fix.
Jeff, What kind of test case do you have for testing this performance issue?
added DJ, may be he can answer the question from Claude below.
I don't have one handy, but it's very easy to construct one. Create a large workspace (such as an eclipse-in-eclipse workspace), then install your listener and perform the following operation many times (for example install a toolbar button that runs the benchmark): ResourcesPlugin.getWorkspace().getRoot().accept(new IResourceVisitor() { public boolean visit(IResource resource) throws CoreException { resource.touch(null); return true; } }); I will send you a plugin that graphically displays the timing information for all installed resource change listeners. For a quick and dirty test you can call: org.eclipse.core.internal.utils.ResourceStats#dumpStats to print out info on how much time was taken by each listener.
fixed > 20020123 However, I cannot see any performance difference whatsoever. I have no test case which proves that this traversal is expensive in any way.
