Bug 215079 - CodeCompletion took 2832 ms.
CodeCompletion took 2832 ms.
Status: REOPENED
Product: webservices
Classification: Unclassified
Component: Code
Dev
All All
: P3 (vote)
: TBD
Assigned To: Denis Anisimov
issues@webservices
EXCEPTIONS_REPORT perf-profileme
: PERFORMANCE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-02 15:26 UTC by Exceptions Reporter
Modified: 2017-08-31 11:40 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
nps snapshot (61.21 KB, application/nps)
2012-07-02 15:26 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
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  ;-)


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo