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.
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.
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 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.
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;
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. :)
On my machine I tried check it. My result:
Calendar.getInstance().getTime() (*1000000 times) = 402ms new Date().getTime(); (*1000000 times) = 18ms System.currentTimeMillis() (*1000000 times) = 16ms
Don't forget about GC (if you use Calendar.getInstance() or new Date())
Depending on your application, you may want to consider using System.nanoTime() instead.
nanoTime returns is relative (usually to the start of the program) and would be nonsense if you tried to turn it into a date. - Dunes
I tried this:
long now = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
new Date().getTime();
}
long result = System.currentTimeMillis() - now;
System.out.println("Date(): " + result);
now = System.currentTimeMillis();
for (int i = 0; i < 10000000; i++) {
System.currentTimeMillis();
}
result = System.currentTimeMillis() - now;
System.out.println("currentTimeMillis(): " + result);
And result was:
Date(): 199
currentTimeMillis(): 3
System.currentTimeMillis() is obviously the fastest because it's only one method call and no garbage collector is required.