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.

Bug 186117 - MultiViewCloneableTopCompon [LowPerformance took 32391 ms.]
Summary: MultiViewCloneableTopCompon [LowPerformance took 32391 ms.]
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal with 1 vote (vote)
Assignee: Miloslav Metelka
URL:
Keywords: PERFORMANCE
Depends on: 201775
Blocks:
  Show dependency tree
 
Reported: 2010-05-13 18:17 UTC by Onofre
Modified: 2017-11-30 17:06 UTC (History)
164 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 166520


Attachments
nps snapshot (66.43 KB, application/nps)
2010-05-13 18:17 UTC, Onofre
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Onofre 2010-05-13 18:17:16 UTC
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
Comment 1 Onofre 2010-05-13 18:17:22 UTC
Created attachment 98969 [details]
nps snapshot
Comment 2 Stanislav Aubrecht 2010-06-08 14:42:41 UTC
org.openide.text.CloneableEditor$DoInitialize.initDocument() is waiting for something in AWT
Comment 3 Jesse Glick 2012-04-02 14:30:08 UTC
Restoring issue metadata. (liszi, please do not edit such fields)
Comment 4 Vladimir Voskresensky 2012-06-14 14:48:03 UTC
There are 400+ duplicates and users still complain
Comment 5 Alexander Pepin 2012-06-14 15:01:35 UTC
It's very annoying and highly visible performance issue reported by 82 users and it's defenitely worth to be fixed after all.
Comment 6 Miloslav Metelka 2012-06-18 14:45:17 UTC
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.
Comment 7 Jaroslav Tulach 2012-06-18 17:01:25 UTC
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
Comment 8 Tomas Stupka 2012-06-21 13:14:06 UTC
> 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
Comment 9 Quality Engineering 2012-06-23 04:36:16 UTC
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.]
Comment 10 Marian Mirilovic 2012-06-25 08:20:42 UTC
This is the stopper for NB 7.2, please evaluate and resolve ASAP.
Comment 11 Miloslav Metelka 2012-06-27 14:47:38 UTC
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.
Comment 12 Petr Cyhelsky 2012-07-17 10:56:45 UTC
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.
Comment 13 Jaroslav Tulach 2012-11-29 12:36:58 UTC
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
Comment 14 Marek Fukala 2012-11-29 13:25:29 UTC
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.
Comment 15 Jaroslav Tulach 2012-11-29 14:54:35 UTC
I've reported the CSS editor problem as bug 222987.
Comment 16 Jaroslav Tulach 2012-11-29 14:59:48 UTC
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
Comment 17 Quality Engineering 2012-11-30 02:49:42 UTC
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
Comment 18 Ralph Ruijs 2012-12-03 12:06:20 UTC
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;
Comment 19 Quality Engineering 2012-12-04 03:17:44 UTC
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
Comment 20 Petr Jiricka 2012-12-06 10:58:34 UTC
(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.