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.
To reproduce the bug do the following steps: 1. Open a File which has 1000 lines of code. 2. Select all (CTRL + a). 3. Try to use TAB to align the code. Then editor response is horrible slow.
Hi, I have created some thread dumps when IDE was in this situation (attached). It seems to me, that most of the time is spent in different listeners (as I supposed). But, we can not be sure without running profiler. So, I would like to ask Petr to run profiler over the IDE for this situation. Please, use file large than 1000 lines, I would recommend at least 2500 (as I used, it tooke much over a minute on my machine). The structure of the file is irrelevant, I have 100-200 lines of code and the rest were comments. I propose these possible solutions: 1. Not to fire so much events. From user's (and most of IDE code), there is only one change - changing whole source file. Not sure whether possible, but one change, one event (one set of events) would make operations over big parts of source incredibly fast. 2. Optimize listeners over document (and caret). In thread dumps, there is updating titles, that consults filesystem. I can not imagine, why to update title to modified, when the title already states the file was modified. The point 2 is more important (for me), as this would make overall (editing) performance better.
Created attachment 5031 [details] Thread dumps
A. I can't measure everybody's code. You can profile it yourself when you know what the problem is. There are wrapper scripts in aisupport/release/bin/unsupported/optimizeit/, try nbopt.sh runide.sh <usual flags passed to the runide.sh> B. There are two things that are wrong: 2. The BaseCaret fires tons of stateChanges and the JTextComponent is listening on them, asking for the actual selection text after each change. It may be sufficient to quench all but the last caret updates during the compoud operation like the formatting is. 1. Yes, there is some overhead in notifyModified, not only in title calculation but also in CookieSet updates (modifySaveCookie). It should be bossible to have a flag whether the title and the cookie are already set to modified and don't touch them till next notifyUnmodified(), but you can't do the filtering too early (Java/Form likes to refuse the modifications in guarded sections). 0. The general problem is that the formatting is done by inserting and removing Strings into the document for each line separately. It may be possible to do one big remove and one big insert, getting rid of the per-line loop, but some parts of the editor won't like it (the same problem we had with reformat in the past: bookmarks, breakpoints, ...) If I "fixed" (read: "commented out") 1. and 2. it got faster but still spent a lot of time in the formatting itself (~2s for 500 line document).
I think that this is rather a long term task for 4.0. I have already written a fast fully swing-compatible document content storage (available in lexer_based_editor_20020404 branch). Unfortunately I can't integrate it into current editor because it does not support mark moving. But once we migrate to lexer we will certainly use it. The other remedy I see is to go through all the document listeners and try to improve the actions performed based on the listening. For example as the formatting is done under atomic lock there are many document events generated but just single undoable edit event at the end of reformatting. The combination of document and undo listening would improve the performance (an example is timer restarting in java module could be done after the undoable edit is generated instead of each document event). Although there must be some care taken for the case when the document events are generated based on undo, it should be feasible because docEvt.getType() is opposite to insertUpdate() and removeUpdate() during undo.
This applies generally on manipulation with large blocks of text (not necessarily java code only) - indenting, commenting, copy/cut/pasting, undo/redoing, etc.
No, this is only about many document modifications at different places in document e.g. selecting a whole text and pressing tab or ctrl+shift+t. The cut/paste for example only makes modification at one place of the document. If these are slow I think it would be better to enter a separate issue to track those.
Okay, except copy/pasting... In fact, it is already a separate issue 27786.
[nbusers] Hang while editing source: I'm using Netbeans 3.4 on Linux (RH 7.3) with Java 1.3.1_03 and I keep experiencing hangs while editing source files. It usually happens after a cut or paste. This time it happened after I deleted a bunch of text. A thread dump is enclosed. I have also been experiencing a problem where changes that I make to a source file are not recognized and therefore not saved. For example, I make some changes, but the file doesn't show as dirty, and I can't save the changes. The reason I mention this here is that it might be related to the hang. When I have the problem of not being able to save, I select and copy all the text, close the file, re-open it, delete the existing text, and then paste. This time the hang occurred at the point where I deleted the existing text. Sometimes it happens at the point of pasting. "AWT-EventQueue-0" prio=1 tid=0x41c3beb8 nid=0x77c runnable [0x4e486000..0x4e486870] at org.netbeans.editor.DocMarks.getOffsetMark(DocMarks.java:671) at org.netbeans.editor.DocOp.getOffsetMark(DocOp.java:376) at org.netbeans.editor.BaseDocument$LineRootElement.getElement(BaseDocument.java:1158) at org.netbeans.editor.BaseDocument.getParagraphElement(BaseDocument.java:1060) at org.openide.text.NbDocument.findLineRootElement(NbDocument.java:83) at org.openide.text.NbDocument.findLineNumber(NbDocument.java:99) at org.openide.text.PositionRef$Manager$PositionKind.getLine(PositionRef.java:467) at org.openide.text.PositionRef.getLine(PositionRef.java:156) at org.openide.text.DocumentLine.getLineNumber(DocumentLine.java:90) at org.openide.text.DocumentLine.notifyChange(DocumentLine.java:392) at org.openide.text.DocumentLine$Set.linesChanged(DocumentLine.java:675) at org.openide.text.LineListener.removeUpdate(LineListener.java:84) at org.openide.util.WeakListener$Document.removeUpdate(WeakListener.java:514) at javax.swing.text.AbstractDocument.fireRemoveUpdate(AbstractDocument.java:223) at org.netbeans.editor.BaseDocument.fireRemoveUpdate(BaseDocument.java:905) at org.netbeans.editor.BaseDocument.remove(BaseDocument.java:632) at org.netbeans.editor.BaseKit$DeleteCharAction.actionPerformed(BaseKit.java:1040) at org.netbeans.editor.BaseAction.actionPerformed(BaseAction.java:137)
Regarding your last stacktrace: the document content is now different, so now you can no longer get the mentioned stacktrace. Please let me know if you experience similar symptoms with current trunk builds. The document content should be now "ideal" from my point of view although I had to made some extra things required for compatibility of org.netbeans.editor.Mark and syntax updating after modifications. But they should not slow things down in general. Now we should make the document listeners faster. IMHO there is place for improvements. Here's a list of document listeners for opened java source: document-listeners[0]=org.netbeans.editor.StatusBar@351061, class=class org.netbeans.editor.StatusBar document-listeners[1]=org.netbeans.editor.Annotations@13ccea, class=class org.netbeans.editor.Annotations document-listeners[2]=javax.swing.JEditorPane$AccessibleJEditorPane@457235, class=class javax.swing.JEditorPane$AccessibleJEditorPane document-listeners[3]=org.netbeans.editor.ext.ExtCaret[x=0,y=0,width=0,height=0], class=class org.netbeans.editor.ext.ExtCaret document-listeners[4]=org.netbeans.editor.BaseTextUI@5138a4, class=class org.netbeans.editor.BaseTextUI document-listeners[5]=org.netbeans.modules.java.JavaParserGlue$SiblingListener@1387c6, class=class org.netbeans.modules.java.JavaParserGlue$SiblingListener document-listeners[6]=org.openide.text.CloneableEditorSupport$Listener@390ff7, class=class org.openide.text.CloneableEditorSupport$Listener document-listeners[7]=org.openide.util.WeakListener$Document[org.openide.text.LineListener], class=class org.openide.util.WeakListener$Document document-listeners[8]=org.netbeans.editor.ext.java.JavaDrawLayerFactory$LParenWatcher@21dba8, class=class org.netbeans.editor.ext.java.JavaDrawLayerFactory$LParenWatcher I'll now go through the editor's document listeners and make sure there are no significant slowdowns.
Implemented atomic lock listening in BaseDocument and modified the BaseCaret to benefit from it. Optimized the replacing of indent - now the removals of the original indent chars are only done if the new indent does not start or end with these old indent chars. Main trunk: Checking in libsrc/org/netbeans/editor/BaseCaret.java; /cvs/editor/libsrc/org/netbeans/editor/BaseCaret.java,v <-- BaseCaret.java new revision: 1.87; previous revision: 1.86 done Checking in libsrc/org/netbeans/editor/BaseDocument.java; /cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v <-- BaseDocument.java new revision: 1.91; previous revision: 1.90 done Checking in libsrc/org/netbeans/editor/Formatter.java; /cvs/editor/libsrc/org/netbeans/editor/Formatter.java,v <-- Formatter.java new revision: 1.35; previous revision: 1.34 done RCS file: /cvs/editor/libsrc/org/netbeans/editor/AtomicLockDocument.java,v done Checking in libsrc/org/netbeans/editor/AtomicLockDocument.java; /cvs/editor/libsrc/org/netbeans/editor/AtomicLockDocument.java,v <-- AtomicLockDocument.java initial revision: 1.1 done RCS file: /cvs/editor/libsrc/org/netbeans/editor/AtomicLockEvent.java,v done Checking in libsrc/org/netbeans/editor/AtomicLockEvent.java; /cvs/editor/libsrc/org/netbeans/editor/AtomicLockEvent.java,v <-- AtomicLockEvent.java initial revision: 1.1 done RCS file: /cvs/editor/libsrc/org/netbeans/editor/AtomicLockListener.java,v done Checking in libsrc/org/netbeans/editor/AtomicLockListener.java; /cvs/editor/libsrc/org/netbeans/editor/AtomicLockListener.java,v <-- AtomicLockListener.java initial revision: 1.1 done
Tried dev build 200302240100, it is much better. Indenting 1000 lines takes about 1 sec on my machine (Ctrl+T ~ 1s, Ctrl+D ~ 2s). About 5 times faster than in NB 3.4.