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
GUEST: Waiting on auto-assist.
Maximum slowness yet reported was 2832 ms, average is 2832
Created attachment 121660 [details]
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.
>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 ;-)