The MultiUIDefaults.get was faster on 1.3.1 than on 1.4, see the attachment.
Comments
EVALUATION
My baseline for this test on 1.3.1 was around 222 miliseconds, and 1.4
(build 76) is 460, yow! This bug, and I belive the others as well, are
very simple, they create an instance and invoke a method on it. In other
words, they are really testing startup.
After looking at the -verbose output I saw we were still loading a
handful (6) of generated classes to look up fields
(GeneratedFieldAccessor). These are being loaded from
java.awt.AWTKeyStroke.getVKValue. Tweaking getVKValue to return a
constant resulted in dropping the time down to 365 miliseconds. I filed
4493578 on this, but there are likely a couple of other bugs already logged
on this. With this test, these are the constants we're asking for:
VK_ENTER
VK_UP
VK_DOWN
VK_PAGE_UP
VK_PAGE_DOWN
VK_ENTER
VK_TAB
VK_TAB
VK_TAB
VK_TAB
VK_TAB
In the following manner:
KeyEvent.class.getField(key).getInt(KeyEvent.class);
The next thing I noticed was that we seemed to be spending a fair
amount of time loading properties files (output from -Xprof). Making
Properties.load do nothing resulted in dropping the time down to 237
miliseconds. Almost what 1.3.1 was! As making the loading do nothing
wasn't conclusive proof that loading properties is significantly
slower, I wrote a test case to load a properties file a bunch of times
and it is quite a bit slower (about 2x when loading 100 files, and
about 14x for the first load). This may not be a problem with
java.util.Properties, but perhaps with the underlying io. Refer to
4493546 for info on this (it has been marked as a nio bug).
Lastly I looked at the classes we're loading, 1.4 is loading
~100 classes more than 1.3.1, 1.3.1 loaded 245 classes, 40% more
loaded classes in 1.4! YOW! They are pretty evenly spread across swing,
awt, util, io/nio and reflect. I've attached the diff.
It is also likely that:
4493299 stringbuffer slower
4493302 String.intern slower
are also affecting this.
Until these other areas are addressed we can really evaluate the Swing side of things, thus, I'll leave this bug in this state until the other bugs are fixed and the reevaluate this.
###@###.### 2001-08-21
One fix that was done for this was to change UIManager to use GetPropertyAction instead of using a subclass of Runnable for extracting properties. This means two less classes than are currently loaded.
###@###.### 2001-09-17
Here is a breakdown of the bug, and timing information between
1.3.1 and 1.4 (build 82). All of this
comes from an single CPU Ultra 60 with times in milliseconds.
bug 1.3.1 1.4 % time diff
4493288 MultiUIDefaults 307 450 46.5% 150
4493295 NewJTextField 70 79 12.8% 9
4493293 NewJMenuBar 1170 1422 21.5% 252
4493294 NewJMenuItem 1681 2047 21.7% 366
4493296 NewJTree 1520 1809 19.0% 289
I was able to locate a couple of areas that seemed slower. These may
be due to bug fixs and we'll just have to live with it, but I figured
I'ld mention them:
. Initializing fonts (X11GraphicsEnvironment.registerFontPaths) is
close to 90 milliseconds slower vs 1.3.1. This will effect all but
MultiUIDefaults and NewJTextField. I determined this by adding
timing code to registerFontPaths in 1.4 and doing something
similiar in 1.3.1.
. The code in core that these tests use uses reflection, which in
these cases seems to be somewhat slower. A simple test case that
is along the lines of the code swing is using in these tests
(except MultiUIDefaults and NewJTextField) shows a slow down of
about 60 milliseconds. This is attached as FooTest.
. Loading of resource bundles is ~80 milliseconds slower. Here are
the resource bundles that are attempted to be loaded:
sun.awt.resources.awt, sun.awt.resources.awt_en,
com.sun.swing.internal.plaf.metal.resources.metal,
com.sun.swing.internal.plaf.metal.resources.metal_en,
com.sun.swing.internal.plaf.basic.resources.basic,
com.sun.swing.internal.plaf.basic.resources.basic_en.
This effects all but NewJTextField.
. Loading of the font properties (sun.awt.FontProperties) seems to be
slightly slower too, ~10ms.
. Loading of properties files in general seems slower than 1.3.1,
both for first time creation and subsequent creation. Using
com/sun/swing/internal/plaf/metal/resources/metal.properties shows a
first time creation difference of ~30ms, and subsequent slowdown of
~20 ms. This likely explains the slown down of looking up
ResourceBundles above, and perhaps the font properties file as
well. I've attached the test case, RBTest, and metal.properties.
. On the Swing side it is possible we could remove a couple of defaults
from the bindings table that aren't really needed anymore. This
shows about a ~10 millisecond improvement. This wouldn't effect the
NewJTextField test. It should be noted this is an optimization we
could have done in 1.3 as well, so this isn't something specific to
1.4. This is primarily pushing off loading of something that most
applications load anyway, so that this may not effect a real
application in anway.
As I was not able to attest any of the slow down to swing, and other bugs
are filed with the other groups, I'm closing this bug out as
'will not fix'.
###@###.### 2001-10-09