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.

Bug 27796 - Operations on TabbedPane must be fast
Summary: Operations on TabbedPane must be fast
Status: RESOLVED INVALID
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P2 blocker (vote)
Assignee: David Simonek
URL: http://performance.netbeans.org/respo...
Keywords: PERFORMANCE
Depends on:
Blocks: 26581
  Show dependency tree
 
Reported: 2002-10-03 17:49 UTC by _ rkubacki
Modified: 2008-12-22 22:48 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
profiling snapshot of the first switch (51.14 KB, application/octet-stream)
2002-12-02 15:23 UTC, Tomas Pavek
Details
profiling snapshot of a second switch (25.02 KB, application/octet-stream)
2002-12-02 15:23 UTC, Tomas Pavek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2002-10-03 17:49:01 UTC
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 *).
Comment 1 David Simonek 2002-11-14 15:54:30 UTC
Peter, please take care of impl of this task. Thx.

Comment 2 Peter Zavadsky 2002-11-18 13:02:46 UTC
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.
Comment 3 Marian Mirilovic 2002-11-22 15:25:32 UTC
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
Comment 4 Tomas Pavek 2002-11-22 16:24:14 UTC
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
Comment 5 Peter Zavadsky 2002-11-25 10:02:44 UTC
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?
Comment 6 Tomas Pavek 2002-12-02 13:58:27 UTC
> 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.

Comment 7 Tomas Pavek 2002-12-02 15:23:05 UTC
Created attachment 8131 [details]
profiling snapshot of the first switch
Comment 8 Tomas Pavek 2002-12-02 15:23:45 UTC
Created attachment 8132 [details]
profiling snapshot of a second switch
Comment 9 Tomas Pavek 2002-12-02 15:34:24 UTC
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...
Comment 10 David Simonek 2005-05-04 12:16:12 UTC
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.