Develop Reference

Java increase or decrease? A performance evaluation [duplicate]

This question already has answers here:
Performance difference between post- and pre- increment operators? [closed]
(2 answers)
Closed 7 years ago.
Is there in JAVA a performance difference between i++; and i--;
I'm not able to evaluate bytecode for this, and I think that simple benchmarks are not reliable because of dependence on a specific algorithm.

im not able to evaluate bytecode
Besides the duplicate which I linked and which shows some general things to consider when asking performance related questions:
Given the following sample code (System.err.println is essentially necessary so that the compiler does not optimize away the unused variable):
public class IncDec {
public static void main(String[] args) {
int i = 5;
i++;
System.err.println(i);
i--;
System.err.println(i);
}
}
Disassembled code:
> javap -c IncDec
Compiled from "IncDec.java"
public class IncDec {
public IncDec();
Code:
0: aload_0
1: invokespecial #8 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: iconst_5
1: istore_1 // int i = 5
2: iinc 1, 1 // i++
5: getstatic #16 // Field java/lang/System.err:Ljava/io/PrintStream;
8: iload_1
9: invokevirtual #22 // Method java/io/PrintStream.println:(I)V
12: iinc 1, -1 // i--
15: getstatic #16 // Field java/lang/System.err:Ljava/io/PrintStream;
18: iload_1
19: invokevirtual #22 // Method java/io/PrintStream.println:(I)V
22: return
}
So, no, there is no performance difference in this particular case on a bytecode level - both statements are compiled to the same bytecode instruction.
The JIT compiler could be free to do any additional optimization though.

In Java, there isn't a difference in speed between the two. At the most basic level, subtraction is simply addition. That is, taking the 2's complement and adding it.

How are these Java byte offsets calculated?

I have the following Java code:
public int sign(int a) {
if(a<0) return -1;
else if (a>0) return 1;
else return 0;
}
which when compiled generated the following bytecode:
public int sign(int);
Code:
0: iload_1
1: ifge 6
4: iconst_m1
5: ireturn
6: iload_1
7: ifle 12
10: iconst_1
11: ireturn
12: iconst_0
13: ireturn
I want to know how the byte offset count (the first column) is calculated, in particular, why is the byte count for the ifge and ifle instructions 3 bytes when all the other instructions are single byte instructions?

As already pointed out in the comment: The ifge and ifle instructions have an additional offset.
The Java Virtual Machine Instruction Set specification for ifge and ifle contains the relevant hint here:
Format
if<cond>
branchbyte1
branchbyte2
This indicates that there are two additional bytes associated with this instruction, namely the "branch bytes". These bytes are composed to a single short value to determine the offset - namely, how far the instruction pointer should "jump" when the condition is satisfied.
Edit:
The comments made me curious: The offset is defined to be a signed 16 bit value, limiting the jumps to the range of +/- 32k. This does not cover the whole range of a possible method, which may contain up to 65535 bytes according to the code_length in the class file.
So I created a test class, to see what happens. This class looks like this:
class FarJump
{
public static void main(String args[])
{
call(0, 1);
}
public static void call(int x, int y)
{
if (x < y)
{
y++;
y++;
... (10921 times) ...
y++;
y++;
}
System.out.println(y);
}
}
Each of the y++ lines will be translated into a iinc instruction, consisting of 3 bytes. So the resulting byte code is
public static void call(int, int);
Code:
0: iload_0
1: iload_1
2: if_icmpge 32768
5: iinc 1, 1
8: iinc 1, 1
...(10921 times) ...
32762: iinc 1, 1
32765: iinc 1, 1
32768: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
32771: iload_1
32772: invokevirtual #4 // Method java/io/PrintStream.println:(I)V
32775: return
One can see that it still uses an if_icmpge instruction, with an offset of 32768 (Edit: It is an absolute offset. The relative offset is 32766. Also see this question)
By adding a single more y++ in the original code, the compiled code suddenly changes to
public static void call(int, int);
Code:
0: iload_0
1: iload_1
2: if_icmplt 10
5: goto_w 32781
10: iinc 1, 1
13: iinc 1, 1
....
32770: iinc 1, 1
32773: iinc 1, 1
32776: goto_w 32781
32781: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
32784: iload_1
32785: invokevirtual #4 // Method java/io/PrintStream.println:(I)V
32788: return
So it reverses the condition from if_icmpge to if_icmplt, and handles the far jump with a goto_w instruction, that contains four branch bytes and can thus cover (more than) a full method range.

The byte offsets can easily be calculated by summing up the size of each instruction before it. Instruction sizes are documented in the JVM specs.
The if<cond> instructions take up more space than the others because in addition to the single byte opcode, they have two extra bytes that specify the offset to jump to if the condition it true.
If you want to experiment further, you could for instance try using larger constants (like, say, 20) in your code. You'll see that the instructions to load those will also use up extra bytes to store the constant value. Commonly used small numbers have one-byte encodings (such as iconst_1) for efficiency.

Java: time complexity of basic operations

I'm going to make some investigations about dividing large arrays/matrix computations among multiple threads. But I need to know the relative time complexity of Java basic operations.
For instance:
int a = 23498234;
int b = -34234;
int[] array = new int[10000];
int c = a + b; // 1
int c = array[234]; // 2
String 1 (summary of two integers) is 10+ times faster than string 2 (memory access)
or (i & 1) == 0 is 10+ faster than i % 2 == 0.
Question: Can you supppose time relations between next operations:
+, * and / operands (suppose on Integer type)
memory access
starting new thread

For performance timing, there are many confounding factors. Rather than try to get exact timings, it's better to understand what's going on and measure what you can.
The time utility will give you detailed stats on an executable, but keep in mind you're timing the JVM which is running the code, not just your code.
You might try the javap disassembler too -- ultimately you'll want to know how your individual operations break down into java bytecode, and the amount of time it takes to execute certain key bits.
Example source code:
public class T {
public static void main(String [] args) {
int x=2;
int y=3;
int z=x+y;
System.out.println(""+x);
}
}
Compiled, then disassembled:
$ javap -c T
Compiled from "T.java"
public class T {
public T();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: iconst_2
1: istore_1
2: iconst_3
3: istore_2
4: iload_1
5: iload_2
6: iadd
7: istore_3
8: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
11: new #3 // class java/lang/StringBuilder
14: dup
15: invokespecial #4 // Method java/lang/StringBuilder."<init>":()V
18: ldc #5 // String
20: invokevirtual #6 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
23: iload_1
24: invokevirtual #7 // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
27: invokevirtual #8 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
30: invokevirtual #9 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
33: return
}
Look at code #6 - that's where the actual addition is happening.
One thing you need to establish is how the operations you're interested in turn into bytecode.
Within the JVM itself, you can use System.getCurrentTimeMillis() as a way of timing, but it won't give you sub-ms resolution. You can also use System.nanoTime(); to get higher precision time, (in the sense that it's sub-ms resolution) but it's less accurate.

Static functions inlining in Java

First code:
public static int pitagoras(int a, int b)
{
return (int) Math.sqrt(a*a + b*b);
}
public static int distance(int x, int y, int x2, int y2)
{
return pitagoras(x - x2, y - y2);
}
distance is called very often. When I compiled it with javac and then decompiled with javap -c I got this bytecode:
public static int pitagoras(int, int);
Code:
0: iload_0
1: iload_0
2: imul
3: iload_1
4: iload_1
5: imul
6: iadd
7: i2d
8: invokestatic #24; //Method java/lang/Math.sqrt:(D)D
11: d2i
12: ireturn
public static int distance(int, int, int, int);
Code:
0: iload_0
1: iload_2
2: isub
3: iload_1
4: iload_3
5: isub
6: invokestatic #34; //Method pitagoras:(II)I
9: ireturn
It seems that javac hasn't optimized second function, distance.
Second code, I think, faster:
public static int distance(int x, int y, int x2, int y2)
{
return (int) Math.sqrt((x - x2) * (x - x2) + (y - y2) * (y - y2));
}
And its bytecode:
public static int distance(int, int, int, int);
Code:
0: iload_0
1: iload_2
2: isub
3: iload_0
4: iload_2
5: isub
6: imul
7: iload_1
8: iload_3
9: isub
10: iload_1
11: iload_3
12: isub
13: imul
14: iadd
15: i2d
16: invokestatic #24; //Method java/lang/Math.sqrt:(D)D
19: d2i
20: ireturn
Is invokestatic so fast that it's the same as inlining static function? Why javac did not optimize this? Or maybe it is in fact optimized and these two codes will give the same, but I'm missing something?

javac doesn't optimise. That's the job of the JVM implementation (typically HotSpot).
There used to be a few optimisations in javac but they complicated the code and allegedly tended to arrange the code so that HotSpot optimisations were inhibited.
HotSpot optimisations are generally done dynamically after thousands of iterations (configurable, default dependent upon whether using "Client", "Server" or tiered versions).
There are some things that javac is required to do by the language specification, such as inlining constants and combining literal strings.

The Java language does not define inlined functions. Many (perhaps most) Just-In-Time (JIT) compilers will dynamically (at run time) replace such static function calls with inlined code.

I believe that performance of both version will be similar because JVM uses JIT to increase the performance.

The kind of optimization you're looking for (inlining) doesn't necessarily occur at compile time, but it's quite possible that the Just in Time (JIT) compiler will perform it during runtime.
So it's unlikely that you'll be able to see the inlining happen at the byte code level, more likely, it'll occur at the native code level during program execution.

The given answers are right : javac does not inline methods as it may not be the best thing to do.
Suppose that the distance() method is called once in a while but not very often. Optimizing it by inlining pitagoras() and stuff would slow down compilation for something that is barely used.
On the other hand, Hotspot knows when a method is called and how many times it is called. If the method is executed often, then Hotspot may inline it and compile it to native code, but only if it improves performances. Remember that Hotspot is the only component that knows if an optimization is a good thing or not.
Also, note that javac may do one optimization : it eliminates dead code. Consider this class :
public class Test {
public final static boolean ENABLED=false;
public static void main(String... args) {
if(ENABLED)
System.out.println("Hello World");
}
}
The compiled bytecode for the main method is this :
public static void main(java.lang.String[]);
Code:
0: return
=> javac detected that the println line could not be reached and removed it.

Java JITC native code generation/execution example?

I'm trying to understand 'native code generation and execution' part of Java JITC, but having a hard time visualizing exactly what happens. E.g. say I have the following class:
class Foo
{
private int x;
public void incX()
{
x++;
}
}
javac generates the following byte code for the method:
public void incX();
Code:
Stack=3, Locals=1, Args_size=1
0: aload_0
1: dup
2: getfield #17; //Field x:I
5: iconst_1
6: iadd
7: putfield #17; //Field x:I
10: return
LineNumberTable:
line 33: 0
line 34: 10
LocalVariableTable:
Start Length Slot Name Signature
0 11 0 this LFoo;
When JITC converts this into native code, what exactly happens? And how is this native code executed by JVM?

When the method gets called sufficiently often to pass the JVM's compilation threshold, the JIT compiles the bytecode into native code, and sets it up so that calls to the function go directly to the natively compiled method.