This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I typed quite a big prefix like Class::bigPrefix| and invoked completion, but it took 3 sec until single choice was displayed
Created attachment 147724 [details] profile-me snapshot
it looks like calculation of documentation blocks completion list display.
If completion result contains exactly 1 element, the asynchronous documentation query blocks a showing results. Reassign to evaluation
Do you have a reproducible test case (a simple test project)? I've never seen similar problem in Java. One question: Does it take 3 sec until the code completion popup is displayed or until the single proposal is inserted into the document? What is your 'Tools->Options->Editor->Code Completion->Insert Single Proposal Automatically' setting? Thanks.
(In reply to Dusan Balek from comment #4) > Do you have a reproducible test case (a simple test project)? I've never > seen similar problem in Java. Try to insert long Thread.sleep into your doc task to simulate. >One question: Does it take 3 sec until the > code completion popup is displayed Yes (and in fact it was 8 sec, I just decided to press profile-me after 5 sec of wainting :) ) > or until the single proposal is inserted > into the document? What is your 'Tools->Options->Editor->Code > Completion->Insert Single Proposal Automatically' setting? Thanks. It is OFF, so I see the single choice in list
btw when "Insert Single Proposal Automatically" is ON, I think c++ doesn't honor it for some reasons anyway
I've tried to insert long Thread.sleep into java completion doc task to simulate your problem and now I can really observe some delays in code completion popup displaying. However, the delays seem to be caused by previous doc computations. My scenario to reproduce is the following: 1) Invoke code completion -> popup is displayed immediately -> long task to compute doc is started 2) Close the completion popup and invoke code completion again -> delay until the doc task started in step 1 finishes. Now, if I modify my long running doc task to check isTaskCancelled() periodically, everything starts to work OK. Could you please check, whether your doc task react on cancelling properly? Thanks.
Dusan, Thanks for the evaluation. We'll add check for cancel, but in some cases cancel can not be checked. Imagine exec of external 'man' utility on remote host => could something be done on infrastructure level to ignore previous tasks?
Unfortunately, there were requests for all AsyncCompletionTasks to share a single dedicated RequestProcessor thread (see #182682). Since than, it is very important that all completion task properly react on cancelling. In case of exec of external 'man' utility on remote host, a possible solution could be to perform computation asynchronously and prevent blocking of the code completion thread.
I see. Please, update javadoc accordingly and it would be great to have (as in Parsing API) the warning if async task doesn't react on cancel for some threshold (50ms in Parsing API?)
Dusan, after some investigation of cancel handling on our side it looks like the solution is going to be too complex. AsynTask should mean async. Could we update the fix for issue #182682? You changed from default processor (with throughput 50) to processor with 1 task which looks like the change of semantic. Could you change RP back to 50 from 1?
The purpose of AsyncCompletionTask is to perform the time consuming code completion computation asynchronously of the AWT EDT. It does not free the code completion implementors from their responsibility to handle cancel events properly. Please note that without proper cancel handling your IDE would end up soon with a lot of threads all of them processing uncancelled documentation tasks to no avail. It would lead to a significant performance problem IMHO.
Dusan, I understand and we are going to support cancel. I just wanted to note, that the current restriction to use RP with throughput "1" is different from previous variant with Default RP which was 50. So, previously it was possible to have slow I/O based provider and ignore it's result (based on cancel) while start the new task at the same time, now it's not possible, because of throughput "1"
Ok. Increasing processor's throughput. Fixed in jet-main. http://hg.netbeans.org/jet-main/rev/47db56133307
Integrated into 'main-silver', will be available in build *201407300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/47db56133307 User: Dusan Balek <dbalek@netbeans.org> Log: Issue #245139: slow code completion for one-element choice - fixed.