9

the following code:

String str1="asdfavaxzvzxvc";
String str2="werwerzsfaasdf";
Object c=str1;
Object d=str2;
System.out.println(c);
long time1=System.currentTimeMillis();
for(int i=0;i<1000000000;i++){
    if(c.equals(d)){
        //System.out.println("asfasdfasdf"); // line 9
    }
}
long time2=System.currentTimeMillis();
System.out.println("time taken in this is "+(time2-time1));

When I uncomment the line 9, that is let print if condition is true, though never it is going to happen since both object are not equal , then it takes 5000+ milli-seconds, and to my surprise by just commenting it takes only 5 milli-seconds, I am not getting the reason, why it takes so much time if it is not commented, since it's never going to get executed...

Is this some sort of branch prediction effect ? or any sort of compiler optimization

Trufa
  • 39,971
  • 43
  • 126
  • 190
peeyush
  • 2,841
  • 3
  • 24
  • 43
  • @Peeyush I tried to improve your question a little bit. Please try to tag your questions are accurately at possible. Also it is not necessary to clarify the language on the title, the tag is enough. Anyway, good question, +1, but please keep in mind this for the next time! – Trufa May 12 '11 at 17:50
  • 1
    hm.. in my machine, the code above takes the same time to run without and with comment. So maybe it is JVM specific? – maks May 12 '11 at 17:56
  • @maks: What JVM are you using? Are you running in debug mode? What VM args? – Matt Ball May 12 '11 at 18:05
  • In the title of your question you say "Problem" Why is this a problem ? You should never do any timing based on a loop. Use timers for that. – Romain Hippeau May 12 '11 at 18:11
  • @Matt Ball: Java HotSpot Client VM. I've run it from netbeans ide and haven't specified any parameter. No, it was not a debug mode. – maks May 12 '11 at 18:12
  • @maks interesting. Using `javac` and `java` in a shell, I see the same results as you; in Eclipse I see the same results as the OP. – Matt Ball May 12 '11 at 18:28
  • @marks n @matt so what would be the possible reason behind this ? does same time mean less time for both ( 5 ms when dead code remove ) or higher time 5s ? – peeyush May 13 '11 at 20:17

4 Answers4

12

The compiler optimizes away dead code — in this case, the entire loop is removed. This might be done by the bytecode compiler (e.g. javac) or, more likely, by HotSpot's JIT.

Why does it still take a whopping 5 ms for this to execute? It doesn't necessarily take all that long. Instead, you might be hitting the resolution limit on System.currentTimeMillis(). Try it with System.nanoTime() instead. FWIW, using nanoTime() agrees with currentTimeMillis() on my Windows system.

You might be interested in reading How do I write a correct micro-benchmark in Java? and Is stopwatch benchmarking acceptable?

Further reading

Community
  • 1
  • 1
Matt Ball
  • 354,903
  • 100
  • 647
  • 710
  • can you just elaborate, what kind of optimisation is this, because of i am getting so much time difference ?.. – peeyush May 12 '11 at 17:48
  • What do you mean, "what kind of optimization is this?" It's an optimization which removes dead code. – Matt Ball May 12 '11 at 17:52
8

The compiler will optimise the entire loop away, because it has no observable side-effects.

Oliver Charlesworth
  • 267,707
  • 33
  • 569
  • 680
1

When the Java "Compiler" compiles your code, it does some optimizing on it. Empty if-clauses are deleted, so you just have a long for-loop, which is pretty fast.

But since the "Compiler" doesn't that the if is always false and the code in the clause is never executed, it test's it every single time. That takes much longer.

Lukas Knuth
  • 25,449
  • 15
  • 83
  • 111
0

This is interesting.

It can't be compile-time optimization. The compiler can't just remove the whole loop body, because there's a call to the equals() method inside the loop. The compiler can't assume that the method will have no side effects, and that it always returns the same result.

But it is possible for the JIT compiler to make those optimizations at run-time. So that's probably what's happening.

Mike Baranczak
  • 8,291
  • 8
  • 47
  • 71