Community
Participate
Working Groups
Created attachment 214006 [details] screenshot I was trying to use it in org.eclipse.jdt.internal.ui.text.correction.AdvancedQuickAssistProcessor to how the feature works. On most occasions I hit a timeout. Though I did get it to work on one or two occasions, which means the installation and settings are probably OK. As shown in the screenshot I was trying to get an AST, in some methods that works and in others it doesn't. e.g. it works everytime in AdvancedQuickAssistProcessor.getIfReturnIntoIfElseAtEndOfVoidMethodProposals(...) but never in AdvancedQuickAssistProcessor.getAddParenthesesForExpressionProposals(...) - Do you need more information from me? - Is there somewhere I can increase the timeout for Call Chain completion engine?
Thanks Deepak. The screenshot and description provides enough information to reproduce, I guess. I'll go for this issue after the 18th. Also Stefan will join again the 23rd. He will probably migrate the chain completion to use the compiler ast and make some performance addition to the algorithm itself.
So there is no way to increase the timeout?
There are two timeouts: 1. JDT's timeout of 4 or 5 seconds 2. our internal timeout after 3.5 seconds for building the callchain graph. This timeout is hardcoded in org.eclipse.recommenders.internal.completion.rcp.chain.ChainCompletionProposalComputer.executeCallChainSearch() and can be changed in source code only ATM. Do you want to dig deeper into this issue?
(In reply to comment #3) > There are two timeouts: > > 1. JDT's timeout of 4 or 5 seconds The only configurable timeout in JDT is for fetching parameter name from attached javadoc, so that does not help here. > 2. our internal timeout after 3.5 seconds for building the callchain graph. > > This timeout is hardcoded in Making this configurable might be an option if the performance cannot be improved significantly.. I can wait for this bug to be fixed, and in the meanwhile continue to try the feature in more situations.
Stefan just signed up to take care of call chain completion. Just for completeness, here the minutes of the meeting what needs to to be done: higher priority: * stop early: Currently, the complete graph is build before search is done. Make the graph builder stop early as soon as the required type is found. * use compiler ast representation instead of JavaElements as recommended by Dani. * try without using a thread pool. I'm not sure we gain a lot when using it (actually we may have even more overhead than gain). However, performance is key :) Lower priority: * configurable timeout: hardcoded atm. Make it configurable via preference page * configurable max chain depth: hardcoded atm. Make it configurable via preference page * "stop-types": are hardcoded. Make them configurable via preference page (e.g., no search should be triggered for java.lang.String) * support for generics: not yet supported. would be nice if List<String> l = $ would actually return types with the right generics. Stefan, please update this bug as soon as the higher priority issues are adressed and the engine is ready for manual tests - or you have any thoughts on the implementation. Thanks, Marcel
chains only support public members. It may be useful to support package/protected/private methods too - if visibility permits. Mostly the visibility checks have to be implemented
Created attachment 215131 [details] Result in AdvancedQuickAssistProcessor.getAddParenthesesForExpressionProposals Stefan refined the algorithm and remove the thread pool. It seems that performance improved much (although he removed the thread pool). Deepak, can you give the latest dev build a try to see if it works for you now in your scenarios and machine?
Deepak, how much performance gain do you think can we expect from working on the compiler ast instead of working on the IJavaElements?
(In reply to comment #7) > Deepak, can you give the latest dev build a try to see if it works for you now > in your scenarios and machine? It feels a bit better, though I did hit the timeout a few times. I guess I will use this for a week or so and see how does it work in real scenarios. A couple of (minor) comments about functionality - You cannot use subwords to filter proposals here :-) - In the screenshot from comment 7, notice the proposals where the first element is a local variable/parameter i.e. the 3rd from top - coveringNode.getAST() and 4th from bottom - node.getAST(). I was a bit surprised that these are far apart in the list. I can see that alphabetical sort is used but I was expecting these to be bunched together since the first element is local variable...
Has been open a long time; will close this for now as I haven't heard complaints recently (maybe computers just good fast enough in the meantime. ;-).
Released Code Recommenders 2.0.7.
