Community
Participate
Working Groups
Provide a dialog to search for method declarations.
New Gerrit change created: https://git.eclipse.org/r/50687
New Gerrit change created: https://git.eclipse.org/r/55298 WARNING: this patchset contains 1021 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
(In reply to Eclipse Genie from comment #1) > New Gerrit change created: https://git.eclipse.org/r/50687 This Gerrit request tries to show all method declarations in a single dialog but fails in terms of performance due to the implementation of MethodsComparator.
(In reply to Eclipse Genie from comment #2) > New Gerrit change created: https://git.eclipse.org/r/55298 > > WARNING: this patchset contains 1021 new lines of code and may require a > Contribution Questionnaire (CQ) if the author is not a committer on the > project. Please > see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire > This Gerrit request contains the prototype to open method declaration through two step dialogs. Even this approach fails in performance for methods like #toString where the second dialog needs to show > 6000 method declarations of toString method in my test workspace. While calling the second search API for all the entries to be displayed in the second dialog, the wait in UI is easily visible for method names with ~200 declarations. This issue would be same with the tree viewer approach also while expanding the method name nodes. Another approach could be to show only method names in the first dialog and once the user selects a method name, delegate the search and results to the Search view. Dani/Markus, please have a look and suggest further.
Noopur: To answer the offline query of why type search is fast - all the required information (including modifiers) are stored in the index files alone; there is no need for a parse of the source. However in the case of methods, most of the required information would have to be determined at the parsing time and hence we need to come up with something that would involve a staged/phased manner fishing out of info.
(In reply to Noopur Gupta from comment #4) > Another approach could be to show only method names in the first dialog and > once the user selects a method name, delegate the search and results to the > Search view. Yes. Without having read your suggestions yet, that's what I also suggested to Dani in a quick discussion. The "Open *" are supposed to give the user instantaneous results. If there are too many matches or if we can't make searches fast enough, we should switch to another interface that is non-modal and where the user also has the possibility to explore multiple matches. The Search view has the added advantage that matches can be grouped at multiple levels and also filters can be used. I think a first iteration can just delegate to the Search view for all matches with multiple results. If we find that to be too cumbersome in common scenarios, we can also change that to always resolve matches with a low number results.
New Gerrit change created: https://git.eclipse.org/r/61965
Updated the Gerrit patch that shows all methods in a single dialog to use the API from bug 483650. Markus, please have a look.
The latest change has performance issues. As discussed in our call, please measure where the performance problem sits.
Created attachment 260428 [details] YourKit snapshot Attaching the YourKit snapshot.
Moving to 4.7 for further performance improvements.
It needs new/improved APIs from jdt.core based on the new index for further performance improvement.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
