How do comparison operators work in java?

Question

Recently someone told me that a comparison involving smaller integers will be faster, eg,

// Case 1
int i = 0;
int j = 1000;
if(i<j) {//do something}

// Case 2
int j = 6000000;
int i = 500000;
if(i<j){//do something else}

so, comparison ( if condition) in Case 1 should be faster than that in Case 2. In Case 2 the integers will take more space to store but that can affect the comparison, I am not sure.

Edit 1: I was thinking of binary representation of i & j, eg, for i=0, it will be 0 and for j=1000 its 1111101000 (in 32-bit presentation it should be: 22 zeros followed by 1111101000, completely forgot about 32-bit or 64-bit representation, my bad!)

I tried to look at JVM Specification and bytecode of a simple comparison program, nothing made much sense to me. Now the question is how does comparison work for numbers in java? I guess that will also answer why (or why not) any of the cases will be faster.

Edit 2: I am just looking for a detailed explanation, I am not really worried about micro optimizations

Answer 1

If you care about performance, you really only need to consider what happens when the code is compiled to native code. In this case, it is the behaviour of the CPU which matters. For simple operations almost all CPUs work the same way.

so, comparison (if condition) in Case 1 should be faster than that in Case 2. In Case 2 the integers will take more space to store but that can affect the comparison, I am not sure.

An int is always 32-bit in Java. This means it always takes the same space. In any case, the size of the data type is not very important eg short and byte are often slower because the native word size is 32-bit and/or 64-bit and it has to extract the right data from a larger type and sign extend it.

I tried to look at JVM Specification and bytecode of a simple comparison program, nothing made much sense to me.

The JLS specifies behaviour, not performance characteristics.

Now the question is how does comparison work for numbers in java?

It works the same way it does in just about every other compiled language. It uses a single machine code instruction to compare the two values and another to perform a condition branch as required.

I guess that will also answer why (or why not) any of the cases will be faster.

Most modern CPUs use branch prediction. To keep the CPUs pipeline full it attempt to predict which branch will be taken (before it know it is the right one to take) so there is no break in the instruction executed. WHen this works well the branch has almost no cost. When it mis-predicts, the pipeline can be filled with instructions for a branch which was the wrong guess and this can cause a significant delay as it clears the pipeline and takes the right branch. In the worst case it can mean 100s of clock cycles delay. eg

Consider the following.

int i; // happens to be 0

if (i > 0) {
   int j = 100 / i;

Say the branch is usually taken. This means the pipeline could be loaded with an instruction which triggers an interrupt (or Error in Java) before it knows the branch will not be taken. This can result in a complex situation which takes a while to unwind correctly.

These are called Mispredicted branches In short a branch which goes the same way every/most of the time is faster, a branch which suddenly changes or is quite random (eg in sorting and tree data structures) will be slower.

Answer 2

Int might be faster on 32-bit system and long might be faster on 64-bit system. Should I bother about it? No you dont code for system configuration you code based on what are your requirements. Micro optinizations never work and they might introduce some unprecedented issues.

Answer 3

Small Integer objects can be faster because java treats them specific.

All Integer values for -128 && i <= 127 are stored in IntegerCache an inner class of Integer