What is faster? System.currentTimeMillis() or Date().getTime()?

Question

What is faster method?

System.currentTimeMillis()

or

new Date().getTime()?

Is there the faster solution to know elapsed time?

What do you mean with faster? As in less CPU cycles? Why does it matter? There is a more accurate method using `System.nanoTime()` though - but you'd still need to get two times and calculate the _elapsed_ time yourself. — Thomas, Mar 24 '16 at 09:06
See [How do I measure time elapsed in Java?](http://stackoverflow.com/questions/1770010/how-do-i-measure-time-elapsed-in-java). — Andy Turner, Mar 24 '16 at 09:09
I'm using `long now = System.currentTimeMillis(); long elapsedTime = now - prevTime;` — Igor, Mar 24 '16 at 09:10
Since [`new Date()`](http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/util/Date.java#165) calls `System.currentTimeMillis()`, it seems reasonably obvious that just calling `System.currentTimeMillis()` directly does less work (e.g. it doesn't create an object, doesn't require an additional method call), and so one would expect it to be "faster". However, that isn't the right method to measure elapsed time. — Andy Turner, Mar 24 '16 at 09:11
@AndyTurner You would be very lucky if a little clock drift is the biggest cause of variation/jitter in your system. Not warming up your code is by far the most common problem. — Peter Lawrey, Mar 24 '16 at 09:19
@AndyTurner the problem with System.nanoTime() is it drifts without correction. So it's great for very short periods, but not so good for longer ones. The correction in the System.currentTimeMillis() is to increase it's accuracy in the long run. — Peter Lawrey, Mar 24 '16 at 09:23

Peter Lawrey · Accepted Answer · 2016-03-24T09:22:20.423

If you do

new Date()

it calls

/**
 * Allocates a <code>Date</code> object and initializes it so that
 * it represents the time at which it was allocated, measured to the
 * nearest millisecond.
 *
 * @see     java.lang.System#currentTimeMillis()
 */
public Date() {
    this(System.currentTimeMillis());
}

so it calls System.currentTimeMillis() AND creates an object you immediately throw away.

If you are very lucky, escape analysis will remove the redundant object and the performance will be much the same.

However, I wouldn't assume Escape Analysis will kick in and just call

long start = System.currentTimeMillis();
// do something
long time = System.currentTimeMillis() - start;

Notes:

object creation is fast, and even though it's redundant, a Date object is small and cheap to create. However it contributes to a) the number of objects in your system and b) general noise in your test if you try to memory profile it. To reduce variation (and speed up your code) you want to reduce memory allocations, esp redundant ones.
this is only accurate to 1 ms and if your system corrects the time while this is running, it can be incorrect (even negative) However, it rarely does this in a dramatic fashion, and instead corrects the clock gradually meaning the time might be out by a small percentage. Given the variation in time due to other things happening on the system, you would be very lucky if this was you biggest problem.
System.nanoTime() could be used instead but this can have a drift of it's own. Over a longer period of time e.g. hours, System.currentTimeMillis() can be more accurate.
if you are trying to write a micro-benchmark, I would ensure the code is warmed up. i.e. ignore the first 2 - 10 seconds as there is a good chance the code isn't warm at this stage.

What is faster? System.currentTimeMillis() or Date().getTime()?

1 Answers1