I investigated switching workspaces and here is what I found.

Testing environment: I did measurement and experiments on my machine
on current dev build. I have PC Dell 700MHz PIII, 512MB RAM, Linux RH
7.1, KDE 2.1.1, JD 1.4.1_01. I used patch for JDK AWT to measure
painting. All components are already loaded so only winsys Swing
manipulation and painting is measured. I measured Editing and GUI
Editing workspaces. Editing workspace with Explorer and Source Editor
(restored). GUI Editing workspace with Explorer, Source Editor and
Form Editor (visible, maximized).

I measured the whole time from clicking on workspace switcher to
finished painting (using patch) and time spent in
WindowManagerImpl.setCurrentWorkspace() (using log). This is called
from AWT thread so this action is synchronous when invoked from
workspace switcher.

Usualy I measured 5 values for the same action because value variance
is high. I compute average so that I can compare if changes I tried to
do in code has some relevant impact on performance or not.

I found that time spent in setCurrentWorkspace is about 20% of whole
time. (It consists mainly from adding/removing frames/top components 
from/to AWT hierarchy.) The rest is painting (from optimize it it is 
37% paint, 17% component validation, 26% setCurrentWorkspace(), 7%
validation from DesktopPane!!!, sum is 87%.). Painting TopComponents
itself takes about 10%.

What I tried:
There was call of revalidate() after workspace switch probably to make
sure that icons of maximized frame will be shown/hidden I removed this
call. It works fine without it. Time spent in setCurrentWorkspace is
shorter but whole time did not change. I tried to change order of
building desktop: Now DesktopPane is added to main window and then
frames and top components are added. I tried to reverse this order but
there was no improvement.

I also measured similar layour of Editing workspace with new winsys
implementation - it was about 50% faster. So there is some space for
improvement but it would require more work and it would be risky. (It
would mean removal of PerimeterPane. In addition new winsys does not
contain center area at all - no JDesktopPane and JScrollPane only
nested JSplitPane. If we would keep center area it would not improve
speed by 50%.

Another possibility is to remove JScrollPane and keep just
JDesktopPane in center area. It would mean removal of scroll bars. It
would require some way how to deal with hidden internal frames
(cascade, tile, move to top left). UI what do you think? I removed
JScrollPane and whole time was about 20% less. I think it is worth to
think about it. (It would save overhead with detecting if scrollbars
shoudl be added/removed and validation of desktop when we want to
paint them.)

Investigation finished. Responsiveness improved as issue #27789.

issue doesn't apply to new window system - verified