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.
Build: NetBeans IDE Dev (Build 201107170600) VM: Java HotSpot(TM) Client VM, 20.1-b02, Java(TM) SE Runtime Environment, 1.6.0_26-b03 OS: Windows 7 User Comments: tnleeuw: Trying to do code completion while IDE is still 'Scanning Projects' Maximum slowness yet reported was 6452 ms, average is 3710
Created attachment 109589 [details] nps snapshot
Sorry - no code completion is available while 'Scanning Projects'. Code completion has nothing to diplay until the up-to-date project metadata are collected. "Scanning in progress..." message should be displayed in the code completion popup requesting user to wait.
*** Bug 203828 has been marked as a duplicate of this bug. ***
*** Bug 199488 has been marked as a duplicate of this bug. ***
> "Scanning in progress..." message should be displayed In my case: http://statistics.netbeans.org/exceptions/exception.do?id=560917, I just got a generic "Please wait..." message. So either there is another performance problem, or we should make sure that the right message is always displayed. Reopening.
After the 'background scanning' merge, Java code completion should no more wait for scanning to be finished. Looking at the relevant exception reports (those after the merge), two distinct problems appear. 1) Javac CancelService is not used in recent dev builds. Fixed in jet-main - http://hg.netbeans.org/jet-main/rev/0134a5c6f0d8 2) Java code completion is waiting for extremely slow ErrorHintsProvider.getLine running under parser lock. Reassigning to jlahoda for further evaluation. In the Petr Jiricka's case - code completion is waiting for a JavaDoc to be loaded from slow HttpURLConnection, so the generic 'Please wait...' message is correct (Code completion is NOT waiting for 'Scanning Projects').
283 reports => P1
This issue is an 'umbrella' one, the exception reporter collects various issues into this one - the only common thing is that those issues block java code completion for one reason or other. since the issues are collected from version 7.0-8.0, I've analyzed those that were reported in the later stages of 7.4 and throughout 8.0 development cycle: ---- [dev] 697808 - slow filesystem / ZIP access 705263 - remote javadoc, filed as issue #240060 694044 - slow CSS3 parser - some diagnostic (org.antlr.runtime.debug.* classes) involved ? Filed as issue #240058 [7.4] 698440, 683892, 697019, 695741, 687910, 685391 - slow filesystem (ZIP) 684139, 684249 - slow organize members: probably complex file, comments are copied to the organized result just to check whether some members must be moved. Filed as issue #240061 692366 - parser result task should support cancel/priorities. Each of the (uninterruptible) hint analysis takes ~1 seconds, but in sum the hints task takes too long time blocking others from parsing results. In this case no mutation which would cancel the pending task is done, only completion is invoked, which does not change the source, but prompt response is expected. Filed as issue #240062 684642 - completion waits on debugger to finish with parsing results. The sources being parsed look rather complex, I drilled down to about 8-10 levels of imports - takes a long for the analysis to complete. ----- I will not pursue further the filesystem/zip slowness. Often, this is an indication of overall low resources or other activities on the system. Other issues were forked/filed as separate bugs as appropriate; all the bugs have significantly lower priority. Closing.