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.
NB Dev (200701091900), JDK 1.6.0(fcs) & JDK 1.5.0_10 Performance tests are measuring regression for "Type a character in editor" test case. This test case : - opens Java file from J2SE project - types a character : for {System.out("")} types 'a' between "" - measure time between the Key press and the last paint event from QuietEditorPane (during 1 second) Current measured values are : 1st usage 848 750 1342 1375 950 905 852 Subsequent usage 647 652 873 849 861 674 666 { Linux FC 3(1.5.0_10) Linux FC 3(1.6.0) Solaris 9(1.5.0_10) Solaris 10(1.5.0_10) Win 2000(1.5.0_10) Win XP(1.5.0_10) Win XP(1.6.0) } It looks like there is a huge regression against previous release (measured values were ~100ms), but it isn't ! I found in the Event log file, that the QuietEditorPane is now repainted few times, instead of one paint as it used to. ======================= Events log : ---------------- 3 KEY PRESSED keycode=65 keytext=A modtext= <- MEASURED 8 ADD - Dirty Region org.openide.text.QuietEditorPane, 121,555,63,15 10 ADD - Dirty Region org.openide.text.QuietEditorPane, 0,555,723,15 11 ADD - Dirty Region org.openide.text.QuietEditorPane, 0,555,723,15 19 PAINTING - done 114 IGNORED - Dirty Region org.netbeans.modules.editor.errorstripe.AnnotationView, 0,0,13,729 213 IGNORED - Dirty Region org.netbeans.editor.StatusBar$Cell, 0,0,65,19 588 ADD - Dirty Region org.openide.text.QuietEditorPane, 0,0,723,729 606 ADD - Dirty Region org.openide.text.QuietEditorPane, 0,0,723,729 634 PAINTING - done <-- MEASURED 700 IGNORED - Dirty Region org.netbeans.modules.editor.errorstripe.AnnotationView, 0,0,13,729" 1021 Measured Time=631 ---------------- From the log above : Add - means the paint event we will take into account (we will measure) Ignore - the paint event we are not measuring =========================== The Key was pressed at time 3ms and 'a' character was painted during the first PAINT at 19ms, it means the Type a character measured value is 16ms -> that is great. ! But unfortunately we measure the last paint event during some period and after a while the QuietEditorPane was repainted (588,606 ms after test case start). AnnotationBar & StatusBar were repainted earlier (114,213). So, what is the reason to repaint the Editor area once again ? Is it possible to avoid this repaint? Thanks in advance for your help.
I guess the extra repaint comes after reparse of the java file that comes after 500ms see JavaSource.REPARSE_DELAY and that may create semantic higlightings. Is that possible to run the test on a plain text file to verify this idea? Thanks.
We are running tests also on a plain text file, so stay tuned I'll look there. Mila I have a question about the semantic higlightings: From this test seems the code in this file has already been highlighted - I wrote only one character and the way it changed the source code - the semantic highlighting is not changed. So question is : do you repaint the semantic highlighting even if there is no change?
Currently, the semantic highlighting always repaints whole editor after each parse. Rewrite of it (to repaint only what is necessary to repaint and to improve some other things) is planned after the new highlighting API is merged.
We will definitely have to have a look at it.
> I guess the extra repaint comes after reparse of the java file that comes after > 500ms see JavaSource.REPARSE_DELAY and that may create semantic higlightings. > Is that possible to run the test on a plain text file to verify this idea? Verified, if I run the same test case in Plain text editor the measured values are close to 10ms , so I think Mila is right. I'll add "Type a character in Plain editor" into our test suite. Anyway thanks for clarification.
Reassigning since this is now mainly about optimizations in java related things.
I was investigating the effect of fix for issue #87642 on repaints, and it looks quite good (for more details on the method below): -for the case denoted here, no (delayed) repaint on behalf of the Java editor should be done (unless there is a compilation error nearby the caret position, but this is not the case as I understand it) -while in some cases the editor is repainted as a whole (on behalf of the Java editor), these cases should not be very common -generally, the span and number of repaints (on behalf of the Java editor) is reduced So, I think this issue can be closed - the original problem is fixed. Marian, is it possible to verify on the testing machines? The method of testing: -I used javax.swing.DebugGraphics to visualize the repaints -I have modified QuietEditorPane by adding the following at the end of the constructor: setDebugGraphicsOptions(DebugGraphics.FLASH_OPTION | DebugGraphics.LOG_OPTION); DebugGraphics.setFlashCount(1); DebugGraphics.setFlashTime(20); RepaintManager.currentManager(this).setDoubleBufferingEnabled(false); -org.netbeans.editor.FontMetricsCache expects to get Graphics2D, but DG is not G2D, so FMC needs to be adjusted. I have simply commented out the cast, and assigned (strikethrough|underline)Offset = 0 and (strikethrough|underline)Thickness = 1. -I have disabled caret blinking to eliminate repaints from the caret -I have changed the reparse delay org.netbeans.api.java.source.JavaSource.REPARSE_DELAY to 3000 (3 seconds) to clearly separate the repaints before and after parse.
Type a character in Java Editor Linux Sol Win 1st usage 49 34 21 Subsequent usage 7 11 6 NB Full Dev[200708151200] JDK 1.6.0_02
Looks like regression happened. Build 200708271200: Type a character in Java Editor [1] 22 ms 100 ms Type a character in Java Editor [2] 7 ms 100 ms Build 200708281200: Type a character in Java Editor [1] 550 ms 100 ms Type a character in Java Editor [2] 568 ms 100 ms Build 200708291200: Type a character in Java Editor [1] 539 ms 100 ms Type a character in Java Editor [2] 544 ms 100 ms
I think I know where the problem is: fix of issue #109886 causes that JPanel in: new javax.swing.JPanel(); is colored using two different attributes collections - one for class and one for constructor. Please note that this may not be visible in all color schemes, as the two attributes collections may be painted using the same color. The problem is that only one of these collections "wins" after each reparse, and so the word "JPanel" may be repainted after each reparse (each time the attributes collection for the given word changes). Unfortunately, I did not have time to actually go through the code and try to find out why this happens and how to fix it. So, I propose to rollback the fix of issue #109886, reopen it, and deal with it later.
I've prepared a fix for this. I've made my own measurements of 'Type a character in Java Editor': - 578/542/557/571 before the fix - 43/6/8/6 after the fix --- Checking in SemanticHighlighter.java; /cvs/java/editor/src/org/netbeans/modules/java/editor/semantic/SemanticHighlighter.java,v <-- SemanticHighlighter.java new revision: 1.22; previous revision: 1.21 done
verified in 200709060000