Community
Participate
Working Groups
currently when using subwords on types, it requires a prefix match to find all potential candidates (that match the prefix) and then allows users to refine this list using the subwords matching strategy. An optimal solution would enable developers use subsequences from the very beginning without the need of a prefix match of at least one character.
E.g., when searching for StringBuilder, one has to enter 'S', wait for the completion window and then complete with 'b'.
same for variable name completion on parameters (in MessageSend). String someString; method($); --> nothing happens if you enter a prefix such as 's': method(s$); --> now you get proposals including someString. Now subwords can work.
completion on method arguments is not supported as we'd like to. See bug 370572 for details.
*** Bug 370572 has been marked as a duplicate of this bug. ***
completion still requires at least one token to be present for argument and type completion but works thereafter "as expected". This feature is currently only implemented in the "Recommenders ALL" completion engine available on e42 HEAD update site.
*** Bug 422550 has been marked as a duplicate of this bug. ***
*** Bug 420953 has been marked as a duplicate of this bug. ***
I've pushed to Gerrit changes for JDT Core https://git.eclipse.org/r/19665 and JDT UI https://git.eclipse.org/r/19666 that relax the prefix filtering to allow substring matches. These changes also refactor the filtering details to be in just 2 different places.
Another serious issue that prevents commercial adoption of Code Recommenders is the performance of (especially) Type and Constructor completion. From all pain points, I tend to rate this as the most serious one.
True, there are some performance problems with JDT's searching, but after seeing one I've always been able to find some mitigation to each, so far. I have been running a custom version of JDT Core/UI for some months now without having that popup show up. There have been a few close calls though, but nothing I could reproduce or trace back to the changes I've made. Have a look at the histories of my git repos here https://github.com/Overruler/eclipse.jdt.core/tree/master and https://github.com/Overruler/eclipse.jdt.ui/tree/master which I keep rebased on top of latest HEAD revisions and are the version I run myself. They should now contain everything on master again after all the Java 8 business.
*** Bug 442391 has been marked as a duplicate of this bug. ***
I'm doing some research on how to improve performance of subwords completion. Completion for types and constructors is by far too expensive. In absolut numbers it takes about 200-800 milliseconds at the moment. Triggering subwords completion with a 1-char prefix (for types and constructors) is 10-20x more expensive compared to triggering code completion after the second letter. Is subwords completion thinkable with a two letter prefix (for types and constructors only)?
(In reply to Marcel Bruch from comment #12) > I'm doing some research on how to improve performance of subwords completion. > > Completion for types and constructors is by far too expensive. In absolut > numbers it takes about 200-800 milliseconds at the moment. Triggering > subwords completion with a 1-char prefix (for types and constructors) is > 10-20x more expensive compared to triggering code completion after the > second letter. > > Is subwords completion thinkable with a two letter prefix (for types and > constructors only)? Honestly, that seems like a wrong question to try to answer. For example, running a search over all the websites in the world takes about 800ms and that's completely fine. What isn't fine is every key press taking 800ms to register when entering the search query! The same is true with the Content Assist popup menu appearing. The Content Assist popup gets populated and displayed in the UI thread. That can involve doing IO from a hard-drive incurring an arbitrarily long delay. See org.eclipse.jface.contentassist.CompletionProposalPopup::showProposals method in the eclipse.platform.text repository for details. If the Content Assist popup could be changed to show "<computing proposals>" until it gets populated from a separate thread then there would be no need to compromise on functionality. Optimizing proposal computation could then be done separately from implementing new features.
(In reply to Timo Kinnunen from comment #13) > If the Content Assist popup could be changed to show "<computing proposals>" > until it gets populated from a separate thread then there would be no need > to compromise on functionality. I assume many would disagree with such a solution. But imho the key part here is that this shouldn't require that much time at all. Other IDEs can do it in no time. Why shouldn't Eclipse? To me this is a matter of how well your indexes work. FWIW, I'm setting up a (student) project which will evaluate whether we could use Lucene as underlying index to code completion. Not sure what the outcome will be.
(In reply to Marcel Bruch from comment #14) > I assume many would disagree with such a solution. But imho the key part > here is that this shouldn't require that much time at all. Other IDEs can do > it in no time. Why shouldn't Eclipse? To me this is a matter of how well > your indexes work. It's more than that. The way the Content Assist works has several problems: 1.) It waits until all results have arrived before any results are shown, rather than displaying them incrementally. This means that it doesn't scale if new proposal computers are added to the mix. 2.) It ranks the proposals as they are computed, rather than when they are added to the UI. This means that already-computed proposals can't have their ranking be recalculated when the search query is refined by the user. 3.) Some Java 8 AST fragments cause proposal computation to become a lot slower than it is for other AST fragments. Java 8's type inference is computationally intensive so it's possible not all of the difference can be optimized away soon or perhaps at all. The combination of these is especially bad when Content Assist is auto-activated while the user is in the middle of typing something. Showing "<please wait>" in that situation isn't the best solution but it's better than locking up the UI, which should be avoided at all costs. Also, I think something like that will be required as part of the solution to the scaling problem. (In reply to Marcel Bruch from comment #14) > FWIW, I'm setting up a (student) project which will evaluate whether we > could use Lucene as underlying index to code completion. Not sure what the > outcome will be. This sounds interesting. Lucene should make it easy to use Javadoc comments in the search as well. That is something people will start to want once they have a good subwords completion :)
FWIW, we spotted serveral performance bottlenecks in Recommenders and one (related to Constructor completions) in JDT. Those have been fixed in in Recommenders 2.1.4 and JDT nightly (available in Mars M7). The issues with empty prefixes remain but the performance should be much better now.
(In reply to Marcel Bruch from comment #16) > FWIW, we spotted serveral performance bottlenecks in Recommenders and one > (related to Constructor completions) in JDT. Those have been fixed in in > Recommenders 2.1.4 and JDT nightly (available in Mars M7). > > The issues with empty prefixes remain but the performance should be much > better now. Classifying this as an enhancement request, which in all likelihood requires upstream changes in the JDT to make it work with empty prefixes.
