Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>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.</p> <blockquote> <p>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.</p> </blockquote> <p>An <code>int</code> 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 e.g. <code>short</code> and <code>byte</code> are often <em>slower</em> 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.</p> <blockquote> <p>I tried to look at JVM Specification and bytecode of a simple comparison program, nothing made much sense to me. </p> </blockquote> <p>The JLS specifies behaviour, not performance characteristics.</p> <blockquote> <p>Now the question is how does comparison work for numbers in java? </p> </blockquote> <p>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.</p> <blockquote> <p>I guess that will also answer why (or why not) any of the cases will be faster.</p> </blockquote> <p>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. e.g.</p> <p>Consider the following.</p> <pre><code>int i; // happens to be 0 if (i &gt; 0) { int j = 100 / i; </code></pre> <p>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.</p> <p>These are called <a href="http://igoro.com/archive/fast-and-slow-if-statements-branch-prediction-in-modern-processors/" rel="nofollow">Mispredicted branches</a> 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 (e.g. in sorting and tree data structures) will be slower.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload