Bug 227645 - org.netbeans.modules.editor.indent.IndentImpl.indentLock: LowPerformance took 49906 ms.
org.netbeans.modules.editor.indent.IndentImpl.indentLock: LowPerformance took...
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: JSP
8.0
All All
: P2 (vote)
: 8.1
Assigned To: Dusan Balek
issues@javaee
EXCEPTIONS_REPORT perf-profileme
: PERFORMANCE
: 252749 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-19 00:27 UTC by Exceptions Reporter
Modified: 2015-08-20 12:51 UTC (History)
34 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
nps snapshot (129.11 KB, application/nps)
2013-03-19 00:28 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2013-03-19 00:27:57 UTC
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
Comment 1 Exceptions Reporter 2013-03-19 00:28:00 UTC
Created attachment 132774 [details]
nps snapshot
Comment 2 Dusan Balek 2013-03-28 13:03:49 UTC
Waiting for an extremely slow JSP parsing.
Comment 3 Marek Fukala 2014-07-29 09:31:06 UTC
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.
Comment 4 Tomas Hurka 2015-05-27 12:15:31 UTC
There is 229 slowness reports - increasing priority to P2.
Comment 5 ecerichter 2015-05-27 12:28:13 UTC
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
Comment 6 Petr Hejl 2015-06-02 12:07:45 UTC
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.
Comment 7 ramujr 2015-06-03 12:33:29 UTC
its irritating users. if i click enter button in jsp page it will takes lot of time to process it.
Comment 8 Petr Pisl 2015-07-16 10:45:56 UTC
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.
Comment 9 Petr Hejl 2015-07-30 09:24:34 UTC
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.
Comment 10 Petr Hejl 2015-08-10 12:34:17 UTC
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.
Comment 11 Petr Hejl 2015-08-11 11:13:34 UTC
Prototyping on branch jsp_typing_hooks.
Comment 12 Petr Hejl 2015-08-11 11:57:34 UTC
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)
Comment 13 Dusan Balek 2015-08-12 12:28:38 UTC
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
Comment 14 Petr Hejl 2015-08-12 13:48:18 UTC
Thanks!
Comment 15 Quality Engineering 2015-08-13 01:19:01 UTC
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.
Comment 16 Petr Hejl 2015-08-20 12:51:33 UTC
*** Bug 252749 has been marked as a duplicate of this bug. ***


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