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.
Closing editor, tab in the editor takes long time. Marian's measurement (time in milliseconds): conditions: - SUN UltraSparc60 / 512 MB RAM / Solaris 5.8 / CDE - JDK1.4.1(01) - [nb_dev](200211140100) , MDI - mounted sampledir close a file in the editor close maximalized SE 313 174 213 close last one tab 138 175 142 close second tab 276 197 211 Test cases described on page : http://performance.netbeans.org/qa/TestSuites.html#close_tab_in_editor
Dafe's measurements - testing conditions: PC Dell Pentium III, 600Mhz, 512 MB memory, JDK 1.4.1, Netbeans Main trunk build, mounted sampledir local filesystem, opened 8 java source files, 3 plain text files. times in milliseconds. action: close java source, new active is another java source: 547, 438, ?1860?, 609, 593 action: close plain text, new active is text: 203, 282 target: should react in 100ms further observations: performance was reported to be even worse when data in editor are modified. candidates for speedup: operations on tabbed pane in core/winsys, removeNotify and paint in editor module.
*** Issue 28947 has been marked as a duplicate of this issue. ***
I take this.
I did more detail mesurement (I closed 10 files, I give average value.) I have Linux, KDE 2.1.1, Pentium III, 700MHz, JDK 1.4.1_01. 1.Text file (copy of short REAME.txt). Whole closing operation takes 283ms, close itself 56ms (20%). 2.Java source file (some files from org.netbeans.core). Whole closing operation takes 711ms, close itself takes 113ms (16%). It seems it is similar to workspace switching. Most of time is spent during refreshing/painting/activating newly displayed component. It will be probably similar to switching tabs/components. I always restarted IDE so that CloneableEditor.componentShowing() is called but it is called during closing component so it is included in closing time. I will try to measure it using OptimizeIt to get more details.
More details: In case of java source files there is running parser in background when I close files. I give details of text file measurement to avoid distortion. 19% is painting and validation 6% timer (mostly 5.5% property sheet delayed updater) 17% closing in CloseButtonTabbedPane$CloseButtonListener.eventDispatched (10% takes TopComponent.close() When I recompute values to 100% I get: 38% painting 12% timer (11% property sheet) 34% closing (20% TopComponent.close()) During measurement CPU is not all the time 100% utilized. So there is some time spent in wait() so we must recompute values from OptimizeIt to get relative ratios. I do not see any way how to improve closing speed.
Because Window System v1 will not be supported from now by our team, all old winsys issues (now "core/window system v1" issues) are going to be closed as WONTFIX. Changes in API which emerged both from UI spec and problems with adjusting to the older API are described in the document http://core.netbeans.org/windowsystem/changes.html. It shows also recommends how the client code should be adjusted to the new window system. If you think this issue apply also to the new winsys then change the subcomponent (to "core/window system") and REOPEN it.
verified