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.
Switching tabs in the editor when a large number of tabs are open Brief freeze while TabbedPane resizes lots of tabs because a "*" character has been added to the title (longstanding enhancement request exists to use color or badging for this instead of *).
Peter, please take care of impl of this task. Thx.
Switching tabs depends also on the editor component to which are switching. Those could be not inited yet (after restart they weren't shown yet). What are the measurements, and what is supposed to do. Please provide concrete cases.
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 operation on tabbed pane - opened all example files in Source Editor - switch tabs 47 46 41 Test cases described on page : http://performance.netbeans.org/qa/TestSuites.html#select_another_tab_in_source_editor http://performance.netbeans.org/qa/TestSuites.html#select_runtime_tab_in_explorer
My measurement of switching: opened 8 small java files (from examples), restarted IDE, then selected the first file and pressed Alt+right arrow repeatedly, two times around. [Build 200211150100, JDK1.4.0, W2K, PIII 733MHz, 512 MB] 1st 500, 328, 157, 265, 344, 187, 406 2nd 219, 140, 141, 156, 140, 188, 141
Marian results seem to be fine, but not the Tomas ones. Surprisingly (for me) the Tomas results are much worser. Could you plase provide what exactly did you measure? To Tomas: I guess the first try is slower because of the lazy init of those components. Anyway also the 2nd attepmt probably don't meet the goals (<100ms). Please could you also provide info, where the time was spent?
> Could you plase provide what exactly did you measure? As stated above, the time between Alt+right is pressed and the next editor component is painted. You may find the technique described at (and may try yourself): http://performance.netbeans.org/responsiveness/measuring/ To me, Marian's results are suprisingly low. We should probabably clarify the difference. > Please could you also provide info, where the time was > spent? I'll attach a snapshot as soon as I can.
Created attachment 8131 [details] profiling snapshot of the first switch
Created attachment 8132 [details] profiling snapshot of a second switch
According to the profiling, it does not look much like winsys issue... I've also repeated my measurements and got times around 100 ms (15 ms more or less) for the _second_ switch round, and also visually the response looks prety fast. I guess there might be a problem with the measuring method which could filter out paints of the editor component (when trying to ignore cursor repaints) and catch only the subsequent properties window repaint. So it looks like only the first switch (which is connected with loading the file) is a problem...
Closing this issue as old and obsolete, editor document switching works OK for me now and also probably meny impl things has changed in editor during the time also. Perf guys, if you still see problems, please file new issue with fresh measurements and assign it to the component which caused the slow-down. I believe winsys is surely not quilty here, thanks.