JDK-4493288 : performance regression in MultiUIDefaults.get
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris
  • CPU: sparc
  • Submitted: 2001-08-17
  • Updated: 2013-11-01
  • Resolved: 2001-10-09
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
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
09-10-2001