Community
Participate
Working Groups
I20100914-0100 I tried to open this reference in my dev workspace: org.eclipse.swt.events.MouseAdapter.mouseDown(MouseEvent) Search took very long (25s) and after progress bar was at the end, it started again at zero (but second search was at least quicker). I think this could be improved a lot if you used the same JDT/Core APIs I would use if I opened the type with Open Type and then used the Quick Outline.
(In reply to comment #0) > I think this could be > improved a lot if you used the same JDT/Core APIs I would use if I opened the > type with Open Type and then used the Quick Outline. Are you also suggesting this for the case when the fully qualified name is not there. e.g. MouseAdapter.mouseDown(MouseEvent) ? ...essentially this would be a faster method search when the type name is available, and could possibly be done in JDT/Core. I will investigate.
(In reply to comment #1) > Are you also suggesting this for the case when the fully qualified name is not > there. e.g. MouseAdapter.mouseDown(MouseEvent) ? Whatever is faster ;-). I did not yet look at the code. Maybe it's also a problem of wrong flags or the scope is expensive to compute, or ... . But it could indeed be a performance problem in JDT/Core. Search for declarations of a fully qualified method name is also quite slow in the Search dialog.
> But it could indeed be a performance problem in JDT/Core. Search for > declarations of a fully qualified method name is also quite slow in the Search > dialog. In my big dev workspace the action is almost unsable in some cases, e.g. "Worker.run" takes more than a minute. This is definitely due to the Java search which also takes about 1'10''.
> This is definitely due to the Java > search which also takes about 1'10''. One reason is probably bug 324189.
Search for method declarations in JDT/Core is not really optimized for TypeName.Method(). It gets all the files which declares Method(), parses those files and if the Method is really there, it finds out if the type is in the hierarchy and if so it reports the Method. This algo is shared across for both declarations and references. Though this algo is necessary for references, it can be optimized for declarations especially when TypeName is given. Either the parsing can be limited to only those types in the hierarchy of the types matching TypeName or only the Types in the hierarchy of TypeName can be looked for the method. Though these optimizations can be done in JDT/Core, the api's you manage to call the JDT/Core can also be modified to fit this :) However, I think the best and easy solution should be the one that Markus had pointed in comment 0.
Created attachment 179231 [details] fix I have changed OpenFromClipboardAction code to use SearchEngine.searchAllTypeNames(...) whenever the type name is available. I have tried this patch on my large dev workspace and performance is really good now. For example results for 'Worker.run()' come within a couple of seconds. I also think that JDT/Core's SearchEngine.search(...) APIs should use the fastest way of searching all the time, so that all clients get the fastest performance possible. I will open a separate bug for that. (The patch also has the fix for Bug 325239 as it was a small fix and affects the same files)
Performance looks much better now! Patch is good except that I'd MEMBER_1/2. Reading the Javadoc the second pattern is for methods - why not name it like that? >(The patch also has the fix for Bug 325239 as it was a small fix and affects >the same files) Verified that this is also working.
Created attachment 179253 [details] fix (In reply to comment #7) > Patch is good except that I'd MEMBER_1/2. Reading the Javadoc the second > pattern is for methods - why not name it like that? Changed to MEMBER_PATTERN and METHOD_JAVADOC_REFERENCE_PATTERN. Darin, if the patch looks good to you then can you please commit it. Thanks!
Applied/Fixed.
Verified in I20101025-1800.
