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 7.3 Beta 2 (Build 201211062253) VM: Java HotSpot(TM) 64-Bit Server VM, 20.12-b01, Java(TM) SE Runtime Environment, 1.6.0_37-b06 OS: Windows 7 User Comments: vriha: Right click on project node in Projects window (HTML/JavaScript project) Maximum slowness yet reported was 37376 ms, average is 26301
Created attachment 130729 [details] nps snapshot
awt waits on write mutex executing in other thread, something is done in html projects that takes a long time. please evaluate, appears to be a chain of events, might not be intentional. related to issue 192354
Created attachment 130923 [details] nps snapshot
This looks like several different performance reports under one issue. Tomas could you please look into it and break it apart if necessary? Thx.
Miloši, in some snapshots there is a call [1] in UI thread which uses read mutex; this read mutex is usually blocked by write mutex (e.g. saving project properties); can you please confirm that using the read mutex in OpenProjectList is OK? I will continue with evaluation, there is a lot of snapshots in th issue... Thanks. [1] org.netbeans.modules.project.ui.OpenProjectList.getDefault()
I went through all the snapshots and reported issues for these areas: apisupport (3 snapshots): issue #232267 busy-io (11 snapshots): WONTFIX fs (1 snapshot): issue #232268 java project (3 snapshots): issue #232269 local-history (2 snapshots): issue #232270 maven (21 snapshots): issue #232271 web (5 snapshots): issue #232272 HTML5 (3 snapshots): issue #232273 The following snapshots are "unknown" to me (I have no idea where to report issues since the problem seems to be mostly outside of NetBeans): snapshot-660837: com.sun.org.apache.bcel.internal.generic.InstructionConstants.<clinit> 12.005057 2 481 ms (12%) 2 481 ms snapshot-661226: I did not find why is the mutex waiting, any help is welcomed. snapshot-664995: com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.<init>() 9.132589 220 ms (9,1%) 220 ms snapshot-665421: com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform() 65.519844 6 889 ms (65,5%) 6 889 ms snapshot-665617: com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer() 61.60225 11 871 ms (61,6%) 11 871 ms com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform() 25.21356 4 858 ms (25,2%) 4 858 ms snapshot-665660: com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform() 71.21945 564 ms (71,2%) 564 ms snapshot-673258: com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform() 36.285397 445 ms (36,3%) 445 ms snapshot-675330: org.netbeans.spi.project.support.ant.AntProjectHelper.saveXml() 98.65684 4 699 ms (98,7%) 4 657 ms snapshot-678052: javax.xml.transform.TransformerFactory.newInstance() 72.2132 14 334 ms (72,2%) 14 334 ms snapshot-678603: com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform() 40.05183 4 999 ms (40,1%) 4 999 ms snapshot-679268: com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer() 22.831173 2 200 ms (22,8%) 2 200 ms If anyone knows what could be done with the snapshots above, please do so. Thanks.
(In reply to comment #5) > Miloši, in some snapshots there is a call [1] in UI thread which uses read > mutex; this read mutex is usually blocked by write mutex (e.g. saving project > properties); can you please confirm that using the read mutex in > OpenProjectList is OK? yes, the current implementation relies on read mutex (as the previous impls used to deadlock quite frequently according to hg log) issue 227291 and issue 192354 are related I guess.
(In reply to comment #7) > yes, the current implementation relies on read mutex (as the previous impls > used to deadlock quite frequently according to hg log) > > issue 227291 and issue 192354 are related I guess. I see, thanks.