JDK-4177488 : GregorianCalendar - poor performance of new
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1998-09-30
  • Updated: 2013-11-01
  • Resolved: 2000-01-20
Related Reports
Duplicate :  
JDK-4230123 - TimeZones loaded unnecessarily
Relates :  
JDK-4763654 - (tz) RFE: consider timezone related files to be put in single jar
Relates :  
JDK-4209900 - Using ResourceBundle.getBundle() kills performance
Description

Name: nl37777			Date: 09/30/98


On my 200 mhz Pentium running w/nt,
new GregorianCalendar()
takes nearly half second. Since this appears
to be the only non-deprecated way to get the
year/month/day etc from a Date, this performance
seems unacceptably poor.

By contrast, the deprecated functions of Date 
that provide the same information take no
measurable milliseconds.
(Review ID: 37783)
======================================================================
Comments
WORK AROUND Name: nl37777 Date: 09/30/98 Use deprecated methods of Date. ======================================================================
11-06-2004
EVALUATION CPU profiling results of new GregrianCalendar(): java.util.TimeZoneData.<clinit> 35% java.text.resources.LocaleElements.getContents() 29% java.text.resources.LocaleElements_ja.getContents() 7% class loader for ResourceBundle 25% TimeZoneData class initialization creates 320 SimpleTimeZone objects that are used for determining the timezone of the environment where JVM is running. It should avoid searching of the 320 SimpleTimeZone objects. For the ResourceBundle performance problem, refer to 4209900. masayoshi.okutsu@Eng 1999-05-18 Prototyping based on the Olson zoneinfo mechanism completely eliminated the TimeZoneData overhead. It saved 200 ms out of 660 ms of "new GregorianCalendar()" under Kestrel on 200MHz Ultra-2. All other overhead comes from ResourceBundle for the TimeZone initialization. So, I'm closing this bug as a dup of 4230123. masayoshi.okutsu@Eng 2000-01-20
20-01-2000