Joda-Time getMillisOfDay() seems to be advancing more rapidly than java.util.Date's getTime() milliseconds value

Question

I've just started using Joda-Time and I ran into something that looks quite strange.

When I sleep for 1 ms and call getMillisOfDay() before and after the sleep, Joda-Time is telling me that 119 milliseconds elapsed. Using java.util.Date (creating an instance before and after the sleep, and taking the difference of the getTime() value returned by each) reports a much smaller elapsed time value (2 milliseconds). which is longer than the 1 milliseconds actual sleep time, but I'm guessing the object overhead of creating the Date had an impact, in any case the elapsed time reported for java.util.Date was far less than that reported by Joda-Time.)

Here is my little test method:

@Test(enabled = true)
public void testsleep() {

    LocalDateTime now = new  LocalDateTime();
    System.out.println("jodatime before millisecs:" + now.getMillisOfDay());
    Thread.sleep(1);
    LocalDateTime now2 = new  LocalDateTime();
    System.out.println("jodatime  after millisecs:" + now2.getMillisOfDay());

    System.out.println("java.util.DATE before call:" + new Date().getTime());
    Thread.sleep(1);
    Date after = new Date();
    System.out.println("java.util.DATE after call:" + after.getTime());

    println "done"
}

output:

jodatime before millisecs:76672505
jodatime  after millisecs:76672624
java.util.DATE before call:1396671472633
java.util.DATE after call:1396671472635

analysis:

jodatime  after millisecs:76672624
jodatime before millisecs:76672505
                        ----------------
                    119 millisecs elapsed according to joda time

java.util.DATE  after call:1396671472635
java.util.DATE before call:1396671472633
                        ----------------
                    2 millisecs elapsed according to java util Date

I thought Joda-Time was better that java.util.Date. Well, I'm sure it is, and I’m just using it wrong. but I don’t see how. Any advice much appreciated !

Answer 1

I wouldn't use neither Date nor LocalDateTime for measuring short intervals of time. The main reason for this in written in your question, there is a considerable overhead for object creation (check out LocalDateTime source code). Also keep in mind that the JVM need some time to warm up (let JVM optimizations kick in and do its magic).

While you shouldn't benchmark like this (there are lot of good benchmark tools for Java), a good low level alternative is System.nanoTime(). StopWatch classes might also come in handy (like Guava, Commons Lang and Spring implementations).

Finally, remember that Thread.sleep is itself subject to precision problems.

// Run several times to *warm up*
for (int i = 0; i < 100; i++) {
    double init = System.nanoTime();
    Thread.sleep(1);
    long end = System.nanoTime();
    System.out.printf("Elapsed time: %.2f milliseconds\n", (end - init) * 1e-6); 
}