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 6.9 Beta (Build 201004200117) VM: Java HotSpot(TM) Client VM, 16.3-b01, Java(TM) SE Runtime Environment, 1.6.0_20-b02 OS: Windows 7 User Comments: Onofre: Criar evento de JButton GUEST: While studing the project http://netbeans.org/kb/docs/java/gui-db.html, run compile file (CarPreview.java). GUEST: Just started the IDE. Maximum slowness yet reported was 32391 ms, average is 12379
Created attachment 98969 [details] nps snapshot
org.openide.text.CloneableEditor$DoInitialize.initDocument() is waiting for something in AWT
Restoring issue metadata. (liszi, please do not edit such fields)
There are 400+ duplicates and users still complain
It's very annoying and highly visible performance issue reported by 82 users and it's defenitely worth to be fixed after all.
Upon top component opening a listener org.netbeans.modules.localhistory.LocalHistory$OpenedFilesListener.propertyChange() gets called which further calls org.openide.text.CloneableEditorSupport.getOpenedPanes() and then org.openide.text.CloneableEditor.getEditorPane() which finally ends up on Object.wait() in org.openide.text.CloneableEditor$DoInitialize.initDocument() Since document and editor component opening represents some inevitable time of working the waiting in CE$DI.initDocument() may take time. The only way I see is to try to avoid local history to avoid the getOpenedPanes() call if possible. On the other hand AWT is the only place where CES.getOpenedPanes() may legally be called. Yarda since (according to hg) you established the waiting in initDocument() are you aware of any better solution? Thanks.
There is a faster, non-blocking way to find out list of opened panes. Maybe localhistory could use it: http://bits.netbeans.org/dev/javadoc/org-openide-text/org/openide/text/NbDocument.html#findRecentEditorPane%28org.openide.cookies.EditorCookie%29
> There is a faster, non-blocking way to find out list of opened panes. Maybe localhistory could use it: > ... NbDocument.html#findRecentEditorPane(org.openide.cookies.EditorCookie) fixed like suggested in core-main #e91182d62030 there were some snapshots where LH wasn't involved, so reassigning back for further evaluation
Integrated into 'main-golden', will be available in build *201206230002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e91182d62030 User: Tomas Stupka <tstupka@netbeans.org> Log: Issue #186117 - MultiViewCloneableTopCompon [LowPerformance took 32391 ms.]
This is the stopper for NB 7.2, please evaluate and resolve ASAP.
Problem partially fixed, we have agreed with Yarda and QE that we downgrade to P3. Remaining problem is that e.g. an o.o.actions.OpenAction makes call to CloneableEditorSupport.open() then CloneableEditor$DoInitialize.initVisual() then CloneableEditor$DoInitialize.initDocument(). CE$DoInitialize.initDocument() ends up in Object.wait() waiting for a thread that initializes document(s) to finish. Making CES.open() asynchronous would not help since it would re-plan into AWT anyway. So another idea is IMHO to attempt DI$initVisual() to make async call to DI$initDocument(). Yardo, could you possibly look at your code around CloneableEditor:776? I've looked at changesets in issue #130657 but I'm not sure whether we could arrange an async call to initDocument() without hitting that fixed deadlock. Thanks.
Not a stopper for 7.2, Tomas's fix lowered the frequency but some new reports are still coming - the underlying problem should be fixed in next release.
Report: http://statistics.netbeans.org/exceptions/exception.do?id=633876 shows that org.netbeans.modules.css.visual.CssCaretAwareSourceTask.runInEDT() 100.0 2,743 ms (100%) 437 ms blocks on calling org.openide.text.CloneableEditorSupport.getOpenedPanes() 100.0 2,743 ms (100%) 437 ms Don't call that method. Try NbDocument.findRecentEditorPane
changeset: 240898:21e2a273a524 summary: #186117 - do not call EditorCookie.getOpenedPanes(), it is slow Thanks Jardo. Passing back as there's lots of other reports not related to css.visual. Updating javadoc of EditorCookie or deprecating it would help as well. Moreover I reckon there are already hundreds of usages of this "bad" method in nb.
I've reported the CSS editor problem as bug 222987.
Another one: http://statistics.netbeans.org/exceptions/exception.do?id=633275 Enablement check(!, making P2) of org.netbeans.modules.refactoring.java.ui.ContextAnalyzer.isFromEditor() 92.7762 10,248 ms (92.8%) 2,127 ms calls org.openide.text.CloneableEditorSupport.getOpenedPanes() 92.7762 10,248 ms (92.8%) 2,127 ms
Integrated into 'main-golden', will be available in build *201211300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/21e2a273a524 User: Marek Fukala <mfukala@netbeans.org> Log: #186117 - do not call EditorCookie.getOpenedPanes(), it is slow
http://hg.netbeans.org/jet-main/rev/4f7789766c0e Removed usages of EditorCookie.getOpenedPanes(). Passing back for further evaluation. There are still a lot of usages of this method, see: http://lahoda.info/index/ui/usages?signatures=METHOD:org.openide.cookies.EditorCookie:getOpenedPanes:()[Ljavax/swing/JEditorPane;
Integrated into 'main-golden', will be available in build *201212040001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4f7789766c0e User: Ralph Benjamin Ruijs <ralphbenjamin@netbeans.org> Log: #186117 - do not call EditorCookie.getOpenedPanes(), it is slow
(In reply to comment #14) > Updating javadoc of EditorCookie or deprecating it would help as well. Moreover > I reckon there are already hundreds of usages of this "bad" method in nb. I reported this as a separate bug 223383.