JDK-4614842 : Performance improvements to GregorianCalendar and Date
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.4.2,5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2001-12-17
  • Updated: 2003-11-05
  • Resolved: 2003-11-05
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.
Other
5.0 b28Fixed
Related Reports
Duplicate :  
JDK-5076007 - Javadoc for methods before() and after() in class java.util.Date incomplete
Duplicate :  
JDK-4936432 - GregorianCalendar should support shared TimeZone
Relates :  
JDK-4981560 - ZipEntry.dosToJavaTime() uses deprecated (and thread-blocking) Date constructor
Relates :  
JDK-6483402 - (date) calling java.util.Date.toString() slows down subsequent calls to the class
Relates :  
JDK-5073554 - java.util.Date is a performance bottleneck
Relates :  
JDK-4930130 - (cal) Provide Gregorian-only calendar as a Calendar subclass
Description

Name: ca25432			Date: 12/17/2001


Performance of Gregorian Calendar is slow, request a re-structure of
GregorianCalendar and Date classes to make them work together better and include
additional functions

======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b28 tiger-beta
29-08-2004
EVALUATION Name: ca25432 Date: 12/17/2001 This feature has been added for Tiger release ====================================================================== This bug report remains as a performance improvement request, not a feature request. The deprecated Date methods showed 80% performance improvement with a new calendar class prototype, which eliminated the static calendar objects. Date.toString showed >70% performance improvement which doesn't use the static DateFormat object. ###@###.### 2002-08-05 Synchronization on the static GregorianCalendar and SimpleDateFormat objects has been eliminated. ###@###.### 2003-09-29 A better solution for the GregorianCalendar is to provide a pure Gregorian calendar implementation (i.e., no BC/AD and cutover support). That would simplify the calculations. However, the abstract Calendar class requires to compute all calendar field values all the time, which is the major cause of the performance problem in GregorianCalendar. ###@###.### 2003-09-29 The following is the performance data with the new GregorianCalendar and Date implementation. (1) date/time conversions Time2Fields 0.80 Fields2Time 0.83 ActualMax 0.12 Date2String 0.45 Time2Fields iterates the conversion from a time value (millisecond offset from the Epoch) to the calendar fields. Fields2Time iterates the reverse conversion with various combinations of calendar fields. ActualMax iterates calls to getActualMaximum() with all the calendar fields. Date2String iterates calls to Date.toString(). The numbers are relative CPU time for the same number of iterations between Tiger b25 (1.00) and the new implementation (using the same server hotspot on a 1-cpu Ultra-60). Smaller numbers are better. (2) Date.toString iterations Another measurement was how many times multiple threads can iterate Date.toString(). The numbers are the relative number of iterations between Tiger b25 (1.00) and the new implementation (using the same server hotspot). Larger numbers are better. Date.toString 3.24 (on 2-cpu Ultra) iteration Date.toString 2.24 (on 1-cpu Ultra) iteration Note that some other performance improvements for Calendar and Date have been integrated before b25. ###@###.### 2003-10-29
29-10-2003