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 cyhelsky. It already has 1 duplicates Build: NetBeans IDE Dev (Build 201205010400) VM: Java HotSpot(TM) Client VM, 23.0-b21, Java(TM) SE Runtime Environment, 1.7.0_04-b20 OS: Linux Maximum slowness yet reported was 22178 ms, average is 22178
Created attachment 118943 [details] nps snapshot
EDT blocked by HtmlStructureItem.getNestedItems() which have no chance to get the data w/o running the parsing task or preparing the data beforehand. The former would however mean creating the StructureItems for the whole file recursively so the first solution (by the way agreed with CSL/Svata) seems to be only one for me under current state of things. The Editor Parsing Loop thread is busy with the first initialization of nu.validator.spec.html5.Html5SpecBuilder.parseSpec() which can take some time, but normally definitively not almost 15 seconds. Cannot it be a low heap memory/GC issue? The solution IMO is so CSL does not try to get the StructureItems in the EDT since based on the previous agreement it is valid to call to potentially slow ParserManager.parse(...)
I have (at least I think I have) moved the expansion off the EDT/Editor loop in changeset http://hg.netbeans.org/jet-main/rev/0cd60fc2abc0 (see defect #212080). The same for refreshing the hierarchy. When updating from new state, the node expansion is delayed & moved to the RP as well. However note that any call to Node.getChildren().nodes() [which is not cached indefinitely!] may lead to parsing. As was noted, it is (IMHO) more acceptable than either locking parser result in memory and/or creating complete structure beforehand.