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 pjiricka. It already has 5 duplicates Build: NetBeans IDE Dev (Build web-main-8659-on-20120925) VM: Java HotSpot(TM) 64-Bit Server VM, 23.4-b01, Java(TM) SE Runtime Environment, 1.7.0_10-ea-b06 OS: Mac OS X User Comments: pjiricka: Running HTML5 application in Chrome pjiricka: Creating HTML5 application medeag: opening file GUEST: Just editing in editor Maximum slowness yet reported was 9549 ms, average is 7507
Created attachment 124862 [details] nps snapshot
EDT blocked in org.netbeans.modules.viewmodel.TreeModelNode$TreeModelChildren.refreshLazyChildren() 100.0 7 716 ms (100%) 0,000 ms trying to obtain post write lock on nodes. The nodes are blocked by org.netbeans.modules.html.navigator.HtmlNavigatorPanelUI.expandNode() 100.0 7 716 ms (100%) 0,000 ms which is waiting for a parsing thread busy with HTML: org.netbeans.modules.html.validation.ValidatorImpl.validate() 100.0 7 716 ms (100%) 7 716 ms
Created attachment 125046 [details] nps snapshot
Created attachment 125403 [details] nps snapshot
I'm not sure, what is html navigator doing wrong. Implementation of method, which you claim is wrong is following: public void expandNode(Node n) { view.expandNode(n); } And view.expandNode(n) javadoc claims, that it can be invoked outside of AWT dispatch thread.
I am claiming there is a chain of invocations which is wrong. Most importantly it is the fact that HTML code holds Children.MUTEX.writeAccess for too long. If you can't see that from the nps, I'll be in office tomorrow, we can discuss that.
Not a navigator issue. Navigator does not hold writeAccess at all.
HtmlNavigatorPanelUI.expandNode() indirectly calls HtmlElementNode.ElementChildren.createNodes() which requires a parsing task to accomplish. During this time the children are locked for reading as Jarda mentioned so the EDT may be stuck as is shown in the snapshot. The parsing task is needed to get the children descriptions when a new node is created. The point was that the whole source is not expanded by default so this lazy children loading saved some time. Also the nodes could hold the element descriptions from older generations of the parse trees since the getChildren() is implemented that it first resolves itself to the current parse tree node and then creates a fresh children descriptions. I'm not sure now if the current implementation always re-sets the nodes descriptions. If so also given the fact that the navigator is always expanded recursively such code is likely not necessary and the instance of HtmlElementDescription may create its children in constructor - which means the full tree of element descriptions is created at once. Honzo, if you need some assistance, feel free to contact me.
Changeset: 8a0a7e6cb603 Author: Jan Becicka <jbecicka@netbeans.org> Date: 2012-10-31 15:29 Message: Issue #218968 - 9.5s in expanding outline view
Integrated into 'main-golden', will be available in build *201211010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/8a0a7e6cb603 User: Jan Becicka <jbecicka@netbeans.org> Log: Issue #218968 - 9.5s in expanding outline view