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.

Bug 215079

Summary: CodeCompletion took 2832 ms.
Product: webservices Reporter: Exceptions Reporter <exceptions_reporter>
Component: CodeAssignee: Denis Anisimov <ads>
Status: REOPENED ---    
Severity: normal CC: alied, misterm, muellermi, toben
Priority: P3 Keywords: PERFORMANCE
Version: Dev   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter: 190344
Attachments: nps snapshot

Description Exceptions Reporter 2012-07-02 15:26:37 UTC 
This bug was originally marked as duplicate of bug 199817, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.

Build: NetBeans IDE 7.2 Beta (Build 201205031832)
VM: Java HotSpot(TM) 64-Bit Server VM, 20.4-b02, Java(TM) SE Runtime Environment, 1.6.0_29-b11
OS: Windows 7

User Comments:
GUEST: Waiting on auto-assist.



Maximum slowness yet reported was 2832 ms, average is 2832
Comment 1 Exceptions Reporter 2012-07-02 15:26:45 UTC 
Created attachment 121660 [details]
nps snapshot
Comment 2 Denis Anisimov 2012-10-01 10:11:43 UTC 
The WS code completion is implemented via AsyncCompletionQuery.
It means that all computational work is done in the separate dedicated thread.
So UI is not blocked by the computational work.
Code completion framework provides a way to cancel time consuming task.
So user is able to cancel CC task at any time.
Computation itself could take some significant time and it's not an issue.
In this particular case CC thread spend most time on the lock acquisition for
runUserTask() of TaskProcessor (not inside real computation logic).

And as I already said there is a way to avoid waiting the CC result.
Comment 3 muellermi 2017-02-15 13:34:33 UTC 
>The WS code completion is implemented via AsyncCompletionQuery.
>It means that all computational work is done in the separate dedicated thread.
>So UI is not blocked by the computational work.

In fact, the UI is not frozen by the long running code completion.
But, it is the user waiting for CC. Thus, even technically not blocked, the user can't work - or can't use CC.
If we want the user not to use CC, then it is better to switch off this freature completely  ;-)