Hi there, I am not entirely sure if this is a bug, but it looks like it to me. We are seeing very long load times (~900 ms) just to do a java.util.Date.toString() I have tracked this problem down to insufficient caching of timezone information. The class where most time is spent is DateFormatSymbols.java. This class reads the LocaleInformation properties files / resource bundle and parses them to get the timezone information. The problem is that an instance of this class is created every single time we format a date, or try to get timezone info. As a test, we cut down the en_us properties file to only have 1 zoneString (UTC). This sped up all calls to 'new DateFormatSymbols();' from 900 ms to ~300 ms. As a proposed fix I think Timezone information should be cached somewhere.. Either making DateFormatSymbols a singleton or having static references to an instance in classes that use it, such as TimeZone.java
FWIW, this bug is the cause behind a performance regression exhibited by Jikes RVM <http://jira.codehaus.org/browse/RVM-781>, which prevents Jikes RVM from switching to newer versions of Classpath (> 0.97.2). Also, it was rediscovered by me after some lengthy investigation: <http://sourceforge.net/mailarchive/forum.php?thread_name=4FBE43CF.1060909%40st.informatik.tu-darmstadt.de&forum_name=jikesrvm-core>.
We can't make DateFormatSymbols a singleton as its constructor is part of the Java API. We can however look into caching the data.
http://git.savannah.gnu.org/cgit/classpath.git/commit/?id=fafe5baa380e6e792ebb973e5a87199373409eb3 should fix it. This simple test: import java.util.Locale; import java.text.DateFormatSymbols; public class TestDFSPerf { public static void main(String[] args) { for (int a = 0; a < 255; ++a) { new DateFormatSymbols(Locale.UK); } } } shows a notable increase. With the new class: $ time /home/andrew/build/cacao-jdk/bin/java TestDFSPerf real 0m0.161s user 0m0.148s sys 0m0.012s Using the old version taken from gcj 4.7: $ time /home/andrew/build/cacao-jdk/bin/java -Xbootclasspath/p:tmp TestDFSPerf real 0m4.005s user 0m3.936s sys 0m0.040s
Similar results by calling new java.util.Date().toString() instead: With fix: real 0m0.628s user 0m0.148s sys 0m0.032s Without fix: real 0m4.122s user 0m4.060s sys 0m0.072s