The cost of Calendar object creation

I spent some quality time with Joshua Bloch this week and by that I mean his book Effective Java. In item number four (the book is organized as a series of fifty items, a format he borrowed from the Effective C++ book by Scott Meyers) he discusses the practice of reusing a single object (instead of creating duplicate objects every time) and uses a Calendar class as an example of an object that you may want to reuse. Near the end of the item, he says “… Calendar instances are particularly expensive to create”, which I’ve heard before, but what does it really mean? Why is it expensive? The JavaDoc for the Calendar class doesn’t attempt to explain why creating instances might be expensive, so I tested it out, just to see how expensive a Calendar object was to create:

long start = System.currentTimeMillis();
for (int i=0; i
and then compared that to the creation of 100,000 Date objects:

long start = System.currentTimeMillis();
for (int i=0; i
On average on my system, the creation of 100,000 Date objects is anywhere from 10 to 30x's as fast as the creation of 100,000 Calendar objects. So while I never doubted Josh, it's obvious he's right. But that doesn't answer the question, why? The only place to go is the Java souce code, which you can download from I'll save you the 48MB download and loosely unwrap the creation of a single Calendar object:

// Calendar c = Calendar.getInstance();
* createCalendar(TimeZone.getDefault(), Locale.getDefault());
  * new GregorianCalendar(zone, aLocale)
    * super(zone, aLocale);
      * setTimeInMillis(System.currentTimeMillis());
        * computeFields();
          * computeFieldsImpl()
            * timeToFields
              * internalSet x 6
            * internalSet x 8

and a single Date object:

// Date d = new Date();
* this(System.currentTimeMillis());
  * long fastTime = date;

So now it should be pretty obvious why it a Calendar object is "... particularly expensive to create." The Calender getInstance() method gets the current time in milliseconds and then unzips that value into the current year, month, date, day of the week, day of the year, milliseconds, seconds, minutes, hour of the day, AM / PM, hour, time zone and daylight savings time offset. The Date object? The only thing it does is store the value of the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC in a member variable.

Tune in next week for more exciting object creation action.

3 thoughts on “The cost of Calendar object creation”

  1. What you left out from your blog entry is that creating 100,000 calendar entries takes 281 milliseconds and 100,000 date instances takes 47 milliseconds.

    So, the fact that Calendar is “more expensive” means nothing to 99.99999999999% of the programmers out there.

  2. Good point, John, but perhaps this is an ideal spot for some easy optimization in the runtime library; why couldn’t it store the relevant bits into the fields when the data is requested, rather than on construction, and then memoizing that data? I wonder if that would be more efficient long-term.. and I wonder how many other places in the library you’d find code like this.

Leave a Reply

Your email address will not be published. Required fields are marked *