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 bug was originally marked as duplicate of bug 180230, 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.3 (Build 201302132200) VM: Java HotSpot(TM) Client VM, 23.7-b01, Java(TM) SE Runtime Environment, 1.7.0_17-b02 OS: Windows XP User Comments: GUEST: Remover verifica
Created attachment 132774 [details] nps snapshot
Waiting for an extremely slow JSP parsing.
JSPProcessor (the JSP's embedding provider for java) calls JspUtils.getCachedParseResult(fobj, true, false) which typically will not be synchronized to the JSP parsing, but it MAY BE unders some circumstances. Possible solution would be to change the call so the code will never be synchronized and always use a former (even incorrect) jsp parsing result. As this area is pretty fragile anyway, I won't better do that now close to the CF.
There is 229 slowness reports - increasing priority to P2.
Let me add: At least in my case, my computer stopped complaining about slowness just because I've migrated to a SSD disk - if I were still working with SATA disks, then I would have lot more slowness reports. I do consider that even using SSD I have considerable disk seek time while working in NetBeans. I've discussed about the ability to reduce index size, but my complains did not render results so far. Using a disk monitor I'm able to see that NetBeans spent hours acessing indexes, which are not being kept in RAM
Ok, it looks like another report where are various issues mixed together. However I went through the 5 latest and 4 of them is caused by JsStructureScanner. So reassigning to JS. I'll file a separate P3 for JSP if I'm able to find the proper profiler snapshot.
its irritating users. if i click enter button in jsp page it will takes lot of time to process it.
The JsStructure issue is fixed. The latest reports are connected with the java hint infrastructure. It looks like many hints are added to the document. The issue contain many reports, but the JsStructure issue is already fixed. Because the reports are mainly from JSP / JSF staff, reassigning to the this area.
I have filed separate issue for JSP before - issue #252749. This issue is getting more and more reports from different area imo. http://statistics.netbeans.org/exceptions/exception.do?id=787002 - java hints/java. http://statistics.netbeans.org/exceptions/exception.do?id=786092 - lot of inactive threads org.netbeans.editor.GlyphGutter, LoggingFlush waiting in java.io.WinNTFileSystem.getLength[native] http://statistics.netbeans.org/exceptions/exception.do?id=785726 - javac/process annotations http://statistics.netbeans.org/exceptions/exception.do?id=785630 - JSP encoding detection I'll file a separate issues at least for these. Tomasi can you prevent more and more reports being add to this and possibly close the issue? Thanks.
The code is using old KeyStrokeHandler. In the AWT call chain there is org.netbeans.modules.editor.indent.IndentImpl.indentLock which waits for parsing. So whenever the parsing takes long the AWT has to wait. Adding Dusan on cc. I believe the code should be rewritten to TypingHooks and such rewrite should hopefully fix the issue. The trouble is there are no unit test for existing functionality. Thus I'm going to waive this issue.
Prototyping on branch jsp_typing_hooks.
Now I have found that even with typing hooks the AWT waits for parsing lock. I'm not sure whether it is an issue with BaseKit or org.netbeans.modules.java.source.save.Reindenter but to me it looks like whenever there's a java embedded in other language it has to be blocking the AWT this way. Dusane, any comment? org.netbeans.modules.parsing.impl.TaskProcessor.acquireParserLock(TaskProcessor.java:446) at org.netbeans.modules.parsing.impl.Utilities.acquireParserLock(Utilities.java:93) at org.netbeans.modules.java.source.save.Reindenter$1.lock(Reindenter.java:214) at org.netbeans.modules.editor.indent.TaskHandler$MimeItem.lock(TaskHandler.java:550) at org.netbeans.modules.editor.indent.TaskHandler.lock(TaskHandler.java:277) at org.netbeans.modules.editor.indent.IndentImpl.indentLock(IndentImpl.java:155) - locked <0x00000000ffa9c5b8> (a java.lang.Object) at org.netbeans.modules.editor.indent.api.Indent.lock(Indent.java:116) at org.netbeans.editor.BaseKit$InsertBreakAction.actionPerformed(BaseKit.java:1342) at org.netbeans.editor.BaseAction.actionPerformed(BaseAction.java:339) at org.netbeans.modules.csl.api.test.CslTestBase.runKitAction(CslTestBase.java:2379) at org.netbeans.modules.csl.api.test.CslTestBase.insertNewline(CslTestBase.java:2418) at org.netbeans.modules.csl.api.test.CslTestBase.insertBreak(CslTestBase.java:2429) at org.netbeans.modules.web.core.syntax.JspTypedBreakInterceptorTest.testEndTag1(JspTypedBreakInterceptorTest.java:98)
Fixed in jet-main - org.netbeans.modules.java.source.save.Reindenter should not wait for parsing lock any more. http://hg.netbeans.org/jet-main/rev/b4bf2d5d5e0e
Thanks!
Integrated into 'main-silver', will be available in build *201508130002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/b4bf2d5d5e0e User: Dusan Balek <dbalek@netbeans.org> Log: Issue #227645 - org.netbeans.modules.editor.indent.IndentImpl.indentLock: LowPerformance - fixed.
*** Bug 252749 has been marked as a duplicate of this bug. ***