Take the 2-minute tour ×

I'm using this little piece of code to test what method is faster:

public void test() {
  long start = System.currentTimeMillis();
  MyDate date = new MyDate();
  int max = 5000;

    Calendar.getInstance().getTimeInMillis(); // <--

  System.out.println("Calendar instance delay: " + (System.currentTimeMillis() - start));
  start = System.currentTimeMillis();

    date.getMillis(); // <--

  System.out.println("My date delay: " + (System.currentTimeMillis() - start));

So, basically, I'm trying to compare the performance between Calendar.getInstance().getTimeInMillis() and MyDate.getMillis() (MyDate is a class created by me).

Well, when I ran the code above, the output were:

Calendar instance delay: 413
My date delay: 2

BUT, when I inverted the order (first called MyDate, and after Calendar), I got:

My date delay: 247
Calendar instance delay: 119

I tried using System.nanoTime(), but the same thing occured: the first code to be tested is the one that took longer.

Anyone knows why this difference happens? Or, is there a way to profile codes accurately without using an external profiler application (just pure Java code)?


share|improve this question
Well firstly you're initialising the date object inside the first timing block. Secondly, you could be hitting GC - 5000 probably isn't enough calls. Finally, is this really a performance issue in your application? –  Philip Whitehouse Mar 3 '13 at 1:06
What's your objection against using a profiler? –  Torious Mar 3 '13 at 1:07
@PhilipWhitehouse No, I'm just using this for testing purposes. –  BloodShura Mar 3 '13 at 1:07
@Torious I'm just using it for testing purposes. –  BloodShura Mar 3 '13 at 1:08
add comment

3 Answers

up vote 4 down vote accepted

To test the performance of "small" code, you have to call it many times. Otherwise, the effects of JIT, caching, and branch prediction mess up your testing. If I call you on the phone to see how long it takes before you answer, I'll get a very different answer if I just called you a few seconds ago.

share|improve this answer
Thank you, David! –  BloodShura Mar 3 '13 at 1:09
+1 In short, you should ignore the results of the first 10,000 iterations. The answer is that System.currentTimeMillis() is the fastest as when you read the code you can see all the others call this and do some extra work. –  Peter Lawrey Mar 7 '13 at 7:46
add comment

There is StopWatch class in commons lang which uses System.nanoTime,



share|improve this answer
Thank you! I'm gonna take a look on that. –  BloodShura Mar 3 '13 at 1:08
add comment

When measuring performance, keep in mind that the the JVM may eliminate code that has no side effects as part of optimization.

To avoid this, you can do the following:

    long a = date.getMillis();
    if (a % 1000 == i) {

Another thing to be aware of is the hotspot-optimization. You should "warm up" your code before measuring.

share|improve this answer
Thank you, mbelow! –  BloodShura Mar 3 '13 at 15:33
add comment

Your Answer


