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.
This issue was reported manually by sdedic. It already has 1 duplicates Build: NetBeans IDE 7.2 (Build 201207171143) VM: Java HotSpot(TM) Client VM, 20.0-b11, Java(TM) SE Runtime Environment, 1.6.0_25-b06 OS: Windows 7 User Comments: petah: Scanning is too slow and make NB unresponsive Stacktrace: java.lang.Exception: Scan canceled. at java.lang.Thread.getStackTrace(Thread.java:1479) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:113) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:106) at org.netbeans.modules.parsing.impl.indexing.PathRegistry.scheduleFirer(PathRegistry.java:820) at org.netbeans.modules.parsing.impl.indexing.PathRegistry.resetCacheAndFire(PathRegistry.java:814) at org.netbeans.modules.parsing.impl.indexing.PathRegistry.access$500(PathRegistry.java:85)
Created attachment 127486 [details] stacktrace
There's a reported cycle between CSS nodes in the log, maybe it contributes to the long scanning time. Please check.
Graph cycle is reported in the log, CSS indexer runs for a long time. Please check.
This bug already has 5 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=194833
The latest report from 7.3 is cause by the recently added support for firing changes from the html indexer. A RequestProcessor task is posted on each file scanned.
fixed in web-main#b1e63790d120 Now the html indexer doesn't fire the change events from the index(...) method for each indexed files, but fires it for each indexer.filesDirty(...) per an indexing root. Remote files seems to work fine, Davide please verify as I may not understand all the aspects of its behaviour.
Thanks Marek, the fix makes sense to me. Sorry about that. I do not think though that it was the cause of this problem. The problem existed before my changes and the latest report does not indicate that posting runnable into dedicated RP is what caused the slowdown, no? On the other hand there are few hundreds of suspicous lines saying: INFO [CssParser]: Created instance org.netbeans.modules.css.lib.nbparser.CssParser@1f387ae
(In reply to comment #7) > Thanks Marek, the fix makes sense to me. Sorry about that. > > I do not think though that it was the cause of this problem. The problem > existed before my changes and the latest report does not indicate that posting > runnable into dedicated RP is what caused the slowdown, no? Hmm, I think so - I saw the exception.fillInStacktrace() triggered from the RP.post() in the stacks which from my previous experience is very slow and causes a big perf. degradation if called too often (which was exactly the case). But I cannot guarantee it is the only culprit. > > On the other hand there are few hundreds of suspicous lines saying: > > INFO [CssParser]: Created instance > org.netbeans.modules.css.lib.nbparser.CssParser@1f387ae This was just some forgotten logging. Should not harm much, at least I've fixed this some tima ago. Thanks David for the verification.
FYI this is wat I ment : Thread id 78, "RepositoryUpdater.worker" (WAITING): java.lang.Throwable.fillInStackTrace(Native Method) org.openide.util.RequestProcessor$SlowItem.fillInStackTrace(RequestProcessor.java:1854) java.lang.Throwable.<init>(Throwable.java:181) java.lang.Exception.<init>(Exception.java:29) org.openide.util.RequestProcessor$Item.<init>(RequestProcessor.java:1768) org.openide.util.RequestProcessor$SlowItem.<init>(RequestProcessor.java:1849) org.openide.util.RequestProcessor$Task.schedule(RequestProcessor.java:1517) org.openide.util.RequestProcessor$Task.schedule(RequestProcessor.java:1495) org.openide.util.RequestProcessor.post(RequestProcessor.java:453) org.openide.util.RequestProcessor.post(RequestProcessor.java:424) org.netbeans.modules.html.editor.indexing.HtmlIndexer.fireChange(HtmlIndexer.java:107) org.netbeans.modules.html.editor.indexing.HtmlIndexer.index(HtmlIndexer.java:98) org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$3.run(Indexable.java:216) ...
(In reply to comment #9) > FYI this is wat I ment : > Thread id 78, "RepositoryUpdater.worker" (WAITING): I had seen it too. But that's just a thread dump of a running code. It does not says this is the bottleneck where I spent 90% of the time. On the other hand if you say that RP.post() is slow in your experience than I absolutely believe you and your fix solves that particular exception report. Thanks for that.
BTW it wouldn't be an issue if we post the tasks to a RP with disabled stacktraces. This is also default RP behaviour when assertions are disabled. see javadoc for RequestProcessor(String name, int throughput, boolean interruptThread, boolean enableStackTraces)
Integrated into 'main-golden', will be available in build *201211300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/b1e63790d120 User: Marek Fukala <mfukala@netbeans.org> Log: #221840 - html indexing slow - firing events from indexer