views:

8672

answers:

5

In Java, what are the performance and resource implications of using

System.currentTimeMillis()

vs.

new Date()

vs.

Calendar.getInstance().getTime()

As I understand it, System.currentTimeMillis() is the most efficient. However, in most applications, that long value would need to be converted to a Date or some similar object to do anything meaningful to humans.

+2  A: 

I prefer using the value returned by System.currentTimeMillis() for all kinds of calculations and only use Calendar or Date if I need to really display a value that is read by humans. This will also prevent 99% of your daylight-saving-time bugs. :)

Bombe
+5  A: 

If you're USING a date then I strongly advise that you use jodatime, http://joda-time.sourceforge.net/. Using System.currentTimeMillis() for fields that are dates sounds like a very bad idea because you'll end up with a lot of useless code.

Both date and calendar are seriously borked, and Calendar is definitely the worst performer of them all.

I'd advise you to use System.currentTimeMillis() when you are actually operating with milliseconds, for instance like this

 long start = System.currentTimeMillis();
    .... do something ...
 long elapsed = System.currentTimeMillis() -start;
krosenvold
A: 

Looking at the JDK, innermost constructor for Calendar.getInstance() has this:

public GregorianCalendar(TimeZone zone, Locale aLocale) {
        super(zone, aLocale);
    gdate = (BaseCalendar.Date) gcal.newCalendarDate(zone);
    setTimeInMillis(System.currentTimeMillis());
}

so it already automatically does what you suggest. Date's constructor default constructor holds this:

public Date() {
    this(System.currentTimeMillis());
}

So there really isn't need to get system time specifically unless you want to do some math with it before creating your Calendar/Date object with it. Also I do have to recommend joda-time to use as replacement for Java's own calendar/date classes if your purpose is to work with date calculations a lot.

Esko
+7  A: 

System.currentTimeMillis() is obviously the most efficient since it does not even create an object, but new Date() is really just a thin wrapper about a long, so it is not far behind. Calendar, on the other hand, is relatively slow and very complex, since it has to deal with the considerably complexity and all the oddities that are inherent to dates and times (leap years, daylight savings, timezones, etc.).

It's generally a good idea to deal only with long timestamps or Date objects within your application, and only use Calendar when you actually need to perform date/time calculations, or to format dates for displaying them to the user. If you have to do a lot of this, using Joda Time is probably a good idea, for the cleaner interface and better performance.

Michael Borgwardt
A: 

Depending on your application, you may want to consider using System.nanoTime() instead.

MikeC
Why, his question was about resources and performance, nanoTime() uses more resources
WolfmanDragon
I mentioned it because it's an option that no one else suggested. The poster did not specify a platform. SDN bug 6876279 suggests that currentTimeMillis() and nanoTime() take about the same in some JDK versions. The poster also did not specify their accuracy needs, for which the original list may be inadequate.
MikeC