Bug 194816 - UI freeze on refresh annotations
UI freeze on refresh annotations
Status: RESOLVED DUPLICATE of bug 197534
Product: editor
Classification: Unclassified
Component: Painting & Printing
7.0
PC Solaris
: P2 (vote)
: 7.0.1
Assigned To: Miloslav Metelka
issues@editor
:
: 194748 194859 (view as bug list)
Depends on: 197747 197743
Blocks: 197680
  Show dependency treegraph
 
Reported: 2011-01-28 15:47 UTC by Alexander Simon
Modified: 2011-06-08 11:23 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
thread dump (19.09 KB, text/plain)
2011-01-28 15:47 UTC, Alexander Simon
Details
list of the biggest objects from heapdump.hprof (1.96 MB, text/plain)
2011-01-31 11:21 UTC, Alexander Simon
Details
java example of low performance of editor (41.04 KB, application/x-gzip)
2011-04-14 07:37 UTC, Alexander Simon
Details
C++ sample (34.16 KB, application/x-gzip)
2011-04-14 10:02 UTC, Alexander Simon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Simon 2011-01-28 15:47:29 UTC
Created attachment 105436 [details]
thread dump
Comment 1 Alexander Simon 2011-01-28 15:51:30 UTC
Information about NB:
>Log Session: Friday, January 28, 2011 6:49:56 PM MSK
>System Info: 
  Product Version         = NetBeans IDE Dev (Build 110128-131a01cfbfd4) (#131a01cfbfd4)
  Operating System        = SunOS version 5.10 running on x86
  Java; VM; Vendor        = 1.6.0_20; Java HotSpot(TM) Client VM 16.3-b01; Sun Microsystems Inc.
  Runtime                 = Java(TM) SE Runtime Environment 1.6.0_20-b02
  Java Home               = /usr/jdk/instances/jdk1.6.0_20/jre
  System Locale; Encoding = en (nb); ISO646-US
Comment 2 Jan Lahoda 2011-01-28 16:03:41 UTC
Seems similar to bug #194748, which does not contain heap info. From this thread dump, it seems that the tenured ("old") generation on heap is almost full. So, a possible problem is a memory leak and the JVM may be under a great stress trying to free some space there. As this seems to happen with a C/C++ source, I would like to ask you to take a heap dump next time the problem occurs and analyze it (or at least check that there is no cnd-related leak). Otherwise, as there probably is no actual deadlock, thread dump is not enough to evaluate and some kind of steps to reproduce are needed. Thanks.
Comment 3 Jan Lahoda 2011-01-28 16:05:35 UTC
*** Bug 194748 has been marked as a duplicate of this bug. ***
Comment 4 Alexander Simon 2011-01-31 11:21:47 UTC
Created attachment 105510 [details]
list of the biggest objects from heapdump.hprof
Comment 5 Alexander Simon 2011-02-01 08:47:26 UTC
Editor consumes about 20K for each line of edited file.
It should be reduced at least in 100 times.
Comment 6 Miloslav Metelka 2011-02-01 10:15:13 UTC
Hi Alexander, could you please test build *201102010000* on
http://bits.netbeans.org/dev/nightly/ whether you notice any improvements? Thanks.
Comment 7 Miloslav Metelka 2011-02-02 15:02:12 UTC
Alexander, is there any way to reproduce the problem? Until we get the steps I mark it as P2.
Comment 8 Alexander Simon 2011-02-02 18:13:49 UTC
(In reply to comment #7)
> Alexander, is there any way to reproduce the problem? Until we get the steps I
> mark it as P2.
I'm waiting for propagation of changes into cnd-main.
Comment 9 Alexander Simon 2011-02-03 10:38:09 UTC
Not fixed.
Step to reproduce:
- download ACE+TAO sources
- build
- create project from binary file ACE_wrappers/build/TAO/tests/IDL_Test/.libs/main
- Open interfaceC.cpp (24K lines)
- do something like "insert space", {"move cursor on CORBA", "reformat", "move cursor on Boolean", "undo"}. Repeat action in {}.
After some steps number of "MultiMark+ParagraphView+BasePosition" are dramatically increased and UI is frozen.

IMHO key moment: editor update content in parallel with updating annotations.
In this case number of "MultiMark+ParagraphView+BasePosition" increased at least in 20 times and we have OOM.
Comment 10 Jan Becicka 2011-02-03 16:43:24 UTC
Alexander, is this beta stopper?
Comment 11 Alexander Simon 2011-02-03 17:44:51 UTC
(In reply to comment #10)
> Alexander, is this beta stopper?
No.
Comment 12 Miloslav Metelka 2011-02-04 09:59:28 UTC
I'm already working on this but it leads to non-trivial changes to annotations handling in the editor.
Comment 13 Jan Becicka 2011-02-04 10:55:34 UTC
not stopper for beta -> P2. P2 still means stopper for fcs
Comment 14 Miloslav Metelka 2011-02-07 17:27:29 UTC
The fix requires to stop reposting of annotation adding into EDT (it used to be necessary for legacy DrawLayer rendering but is no longer necessary for highlighting layers and current view hierarchy).
 The replanning complicates the whole process of annotations attaching and the other incoming requests in EDT (modelToView(), painting etc.) result in a slow down unacceptable for large files.
 The change is also beneficial for NbEditorDocument's code since there used to be a hack because of the EDT re-planning due to possibly reversed order of attaching/detaching coming in EDT.
The only impl of NbDocument.Annotatable should be NbEditorDocument (which is now rewritten) and the openide.text tests pass. The change is documented in openide.text apichanges.

http://hg.netbeans.org/jet-main/rev/db82e4e0fbcc
Comment 15 Quality Engineering 2011-02-08 06:16:56 UTC
Integrated into 'main-golden', will be available in build *201102080000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/db82e4e0fbcc
User: Miloslav Metelka <mmetelka@netbeans.org>
Log: #194816 - UI freeze on refresh annotations.
Comment 16 Miloslav Metelka 2011-02-09 15:52:29 UTC
*** Bug 194859 has been marked as a duplicate of this bug. ***
Comment 17 Alexander Simon 2011-04-14 06:40:31 UTC
Sorry, but original bug did not fixed.
As I understand change set removed restriction of "attach/detach in EDT".
So to fix original bug you should do one of following:
- fix client code (for example AnnotationsHolder in cnd and java clusters)
- create bugs against "attach/detach" clients
- reassign bug to cnd

I would suggest another way to fix bug.
First of all I want to note that root cause of problem is:
- low performance of adding/removing one annotation.
I believe that adding/removing collection of annotations can be implemented as fast as adding/removing one annotation.
So to fix problem provide document efficient method that add/remove collection of annotations.
Comment 18 Alexander Simon 2011-04-14 07:37:50 UTC
Created attachment 107744 [details]
java example of low performance of editor

Extract project, open in NB and open in editor file Big.java.
See a bunch of editor problems that C/C++ user have in real projects.
Comment 19 Alexander Simon 2011-04-14 10:02:02 UTC
Created attachment 107747 [details]
C++ sample

Open Big.cc file
Comment 20 Miloslav Metelka 2011-04-14 12:17:11 UTC
Regarding Big.cc it seems that there's some performance problem in cnd - a thread "Provider asynchronous-merger prosess" keeps CPU at 100% for rather long time.
I've entered issue #197739.
Comment 21 Jan Lahoda 2011-04-14 12:54:33 UTC
Note that the Java's AnnotationHolder adds/removes the annotations off-AWT in 7.0. On the provided. There appear to be some problems on Java side - Mila filled #197743.
Comment 22 Miloslav Metelka 2011-04-14 13:03:29 UTC
For Big.java there's some hints related stuff computation. I've entered issue #197743.

Anyway regarding editor's annotations handling the o.n.editor.Annotations is definitely a candidate for performance improvements. For example it's not necessary to compute annotations combinations on a line until the line is about to be displayed. I have entered issue #197747 for that.
Comment 23 Quality Engineering 2011-04-20 05:01:45 UTC
Integrated into 'main-golden', will be available in build *201104200000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/6aef47a064ac
User: Jesse Glick <jglick@netbeans.org>
Log: #194816 change entry was missing its summary.
Comment 24 Miloslav Metelka 2011-06-08 11:23:58 UTC
Dup of issue #197534 since Annotations highlighting layer will have fixed size so annotation changes should not trigger view rebuilding.

*** This bug has been marked as a duplicate of bug 197534 ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo