CODEWITHSUNDEEP
javaperformanceif-statementconditional-statements
Priyank Doshi
Priyank Doshi

Reputation: 13151

Performace difference of two small construct

I was wondering is there any performance difference between following two?

if(i>=0){
    //some code here
}

//and

if(i>-1){
    //some code here
}

And what about following two?

if(i>=0){
    //some code here
}

//and

if(i>0 || i==0){
    //some code here
}

Is >= would be internally converted to > || == ?

P.S. The performance difference would be very little,may be negligible, but I want to know is there any performance difference at all ?

Upvotes: 0

Views: 72

Answers (5)

Stephen C
Stephen C

Reputation: 718698

The answer is going to be platform dependent; i.e. it will depend on the hardware platform, the ISA, and the JIT compiler in your Java installation.

And this makes it pretty pointless to know the answer ... since you don't want to be wasting your time micro-optimizing for a specific hardware / ISA / JIT compiler platform.

But if you DO need to know, then you should benchmark it ... taking care to do all of the things you need to do to get valid results from a Java benchmark.

FWIW - I think that a modern JIT compiler will generate equivalent native code for the subcases in all both cases; i.e. it should make no difference to performance which one you use. But i>0 || i==0 is pointless obfuscation, and should be avoided for that reason.

Upvotes: 1

mikera
mikera

Reputation: 106351

It's implementation dependent, so you'll need to benchmark for your specific platform if you really care.

Having said that:

  • The first two are probably equivalent on any reasonably modern hardware / JVM combination. All comparisons tend to perform the same on modern hardware.
  • For the second two the first option is possibly faster. While a clever compiler will spot the equivalence and produce the same single native operation, I believe that some current JIT compilers won't spot this. But you should be using the first option anyway since it's much clearer to read and maintain.

Upvotes: 0

jjathman
jjathman

Reputation: 12604

On a modern JVM I think this type of thinking is just pointless. The JVM doesn't just compile code and stop. It learns about your code at runtime and modifies its behavior accordingly. Now I'm not a compiler expert but from what I understand the JVM can be so smart that it may basically optimize your entire if statement away at runtime if it sees the value of i always evaluating to true or false.

Whenever you feel like "optimizing" your code in micro ways like this, just stop and remind yourself that you are not as smart as the JVM because it gets to cheat. It gets to actually see what your code does when it's running and change its behavior accordingly.

Check out this excellent transcript from a talk by Steve Yegge that gives a hint at to how impressive a VM can be. And this was several years ago now!

http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

Added Better Example

These are the slides from a talk by Josh Bloch talking about how micro benchmarking is impossible now. You can not look at a source line of code and know what the JVM will do at runtime. My favorite slide is how short circuit operators like && used to always be faster but on modern hardware this isn't always true anymore. Completely counter intuitive which means you should stop trying to go down this path.

http://wiki.jvmlangsummit.com/images/1/1d/PerformanceAnxiety2010.pdf

Upvotes: 2

Sean
Sean

Reputation: 2771

You can check the the corresponding assembly code using objdump, or examine how many instructions actually retired at run-time. However, with pipeline, the actual cycles needed may not be so clear.

Upvotes: 0

uzyn
uzyn

Reputation: 6683

I believe the first method is better.

The second one requires 3 comparisons:

  1. if (i > 0)
  2. if (i == 0)
  3. Boolean OR of 1. and 2.

However, the actual results still depends on if a compiler is able to optimize the 2 codes to be identical (since they are doing the same thing).

Maybe a benchmark is a better idea.

Upvotes: 0

Related Questions