Which is faster? ++, + = or x + 1?

Question

I am using C # (this question is also applicable for similar languages ​​such as C ++), and I am trying to find the fastest and most efficient way to increase. This is not one or two increments in my game, like 300 increments per second. As the frames of each sprite on the screen increase, the speed and position of my rpg symbol, the camera offset, etc. So I think which method is most effective? for example, to increase 5 y_pos for each movement I can do:

one.

 Player.YPos += 5; 

2.

 Player.YPos = Player.YPos + 5; 

3.

 for (int i = 0; i < 5; i++) { Player.YPos++; } 

What is the most effective (and fastest)?

Answer 1

(The answer specific to C # like C ++ can vary significantly.)

1 and 2 are equivalent.

3 will definitely be slower.

Having said that by doing this only 300 times per second, you will not notice any difference. Do you know how many computers can do in terms of raw processor + memory per second? In general, you should write code for clarity as the most important. By all means, worry about performance — but only when you have a way to measure it, to: a) indicate whether you need to worry, and b) if any changes have affected performance.

In this case, I would say that option 1 is the clearest, so I would use.

Answer 2

Options 1 and 2 will lead to the creation of identical code by the compiler. Option 3 will be much slower.

It is a mistake that i++ faster than i += 1 or even i = i + 1 . All worthy compilers will turn these three instructions into the same code.

For a trivial operation like adding, write the cleanest code and let the compiler worry about making it fast.

Answer 3

The compiler should create the same assembly for 1 and 2, and it can expand the loop in option 3. When you come across similar questions, a useful tool that you can use to empirically test what happens is to view the assembled assembly by the compiler. In g ++, this can be achieved with the -S switch.

For example, both options 1 and 2 create this assembler when compiled using the g++ -S inc.cpp (using g ++ 4.5.2)

 main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 movq %rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 addl $5, -4(%rbp) movl $0, %eax leave .cfi_def_cfa 7, 8 ret .cfi_endproc 

g ++ creates a significantly less efficient assembler for option 3:

 main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 movq %rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 movl $0, -8(%rbp) jmp .L2 .L3: addl $1, -4(%rbp) addl $1, -8(%rbp) .L2: cmpl $4, -8(%rbp) setle %al testb %al, %al jne .L3 movl $0, %eax leave .cfi_def_cfa 7, 8 ret .cfi_endproc 

But with optimization on (even -O1) g ++ produces this for all 3 options:

 main: .LFB0: .cfi_startproc leal 5(%rdi), %eax ret .cfi_endproc 

g ++ not only expands the loop in option 3, but also uses the lea instruction to add to a single command instead of faffing about with mov .

Thus, g ++ will always create the same assembly for options 1 and 2. g ++ will create the same assembly for all 3 options only if you explicitly enable optimization (this is the behavior you are likely to expect).

(and it looks like you should check out the assembly released by C # , although I have never tried this)

Answer 4

They are the same:

 static void Main(string[] args) { int a = 0; a++; a +=1; a = a+1; } 

The above code in ILSpy :

 private static void Main(string[] args) { int a = 0; a++; a++; a++; } 

In addition, the IL for all these programs is also the same (in Release mode):

 .method private hidebysig static void Main(string[] args) cil managed { .entrypoint // Code size 15 (0xf) .maxstack 2 .locals init ([0] int32 a) IL_0000: ldc.i4.0 IL_0001: stloc.0 IL_0002: ldloc.0 IL_0003: ldc.i4.1 IL_0004: add IL_0005: stloc.0 IL_0006: ldloc.0 IL_0007: ldc.i4.1 IL_0008: add IL_0009: stloc.0 IL_000a: ldloc.0 IL_000b: ldc.i4.1 IL_000c: add IL_000d: stloc.0 IL_000e: ret } // end of method Program::Main 

Answer 5

Options 1 and 2 will result in identical code after compilation. Option 3 will be much slower because its results lead to more code for the loop involved.