JDK-6690263 : Nimbus L&F: Nimbus startup is too slow
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-04-17
  • Updated: 2011-02-16
  • Resolved: 2008-06-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
6u10 b26Fixed
Startup time for a large Swing application using Nimbus is unacceptably long compared to Metal. I performed some basic profiling and found that the majority of the CPU time is spent initializing NimbusStyle. This is not surprising since at least one for each component it must run through this initialization code. The code was originally written to be easy to read and correct -- but it is in a performance critical loop and now needs to be optimized.

In particular, a large amount of time was spent creating HashMaps and populating them. This could be optimized by using a static HashMap (since all this code should only ever be run on the EDT). Further, each time a style is initialized it will parse through all the entries in the UIDefaults class looking for entries that pertain to it. In this case, we can precompile the data such that it is retrieved from a datastructure and parsed only when UIDefaults changes, as opposed to parsing on each loop.

Also, we use String.split(","), for splitting of the states, which invokes regular expressions and is slowing things down as opposed to handling this splitting manually. Also, we use the enhanced for loop in these methods which creates a bunch of unnecessary iterators.

Nearly every method in the profiler that appeared slow eventually led to the two init methods in NimbusStyle. Improving those methods should lead to a much faster startup time.

EVALUATION Richard has fine tuned a lot of the NimbusStyle code and added Style caching back in which offers upto 50% improvment in startup times.