Is a += 5 faster than a = a + 5?

Question

I'm currently learning about operators and expressions in C# and I understood that if I want to increment the value of a variable by 5, I can do it in two different ways: a = a + 5 and a += 5. Apparently, the second way is easier and faster to write and more pleasant to read. However, computer-wise, is a += 5 faster than a = a + 5? Does it take less time to compile and execute than the longer version of the expression?

Fredrick

It's just syntactic sugar. – Brickwork

If that's the biggest performance problem in your code, you are doing great. Move on. Implement more useful features. – Chub

"I'm currently learning [..] C#" - then you should not worry about performance issues, especially not such low-level ones. If you're really worried about the performance of these most basic expressions, benchmark them. – Wakefield

Given that you want to go deep under the hood, I suggest you get a .NET decompiler and check the generated byte code. Just search for "Free .NET Decompiler" and you should get a couple options. – Baronet

@wdosanjos For low-level concerns like this (though perhaps not this case specifically), the bytecode can be misleading and you should look at the JIT compiled code. – Gough

Answer 1

However, computer-wise, is a += 5 faster than a = a + 5?

Both are same, first(a += 5) is equal to second a = a + 5.

You may see:

+= Operator (C# Reference)

An expression using the += assignment operator, such as x += y is equivalent to x = x + y except that x is only evaluated once. The meaning of the + operator depends on the types of x and y (addition for numeric operands, concatenation for string operands, and so forth).

So it depends on type of a and in those situations where multiple threads are accessing your variable a you could get different results. But for most of the other case it would be same:

For code:

static void Main(string[] args)
{
    int a = 10;
    a += 5;
    Console.WriteLine(a);
}

Build in Release Mode the IL is

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       14 (0xe)
  .maxstack  2
  .locals init ([0] int32 a)
  IL_0000:  ldc.i4.s   10
  IL_0002:  stloc.0
  IL_0003:  ldloc.0
  IL_0004:  ldc.i4.5
  IL_0005:  add
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  call       void [mscorlib]System.Console::WriteLine(int32)
  IL_000d:  ret
} // end of method Program::Main

Same IL is generated through code:

static void Main(string[] args)
{
    int a = 10;
    a = a + 5;
    Console.WriteLine(a);
}

IL (same) is:

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       14 (0xe)
  .maxstack  2
  .locals init ([0] int32 a)
  IL_0000:  ldc.i4.s   10
  IL_0002:  stloc.0
  IL_0003:  ldloc.0
  IL_0004:  ldc.i4.5
  IL_0005:  add
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  call       void [mscorlib]System.Console::WriteLine(int32)
  IL_000d:  ret
} // end of method Program::Main

Treponema

If it gets translated, is it just that much slower? – Cinder

@Cinder it gets translated by the compiler, so there's no run-time overhead of this translation. – Chub

@SuperPrograman, slower should only be considered at execution. So at execution it doesn't matter, it is already compiled. – Treponema

@Treponema It's wrong. The two aren't equivalent, although similar. – Brabble

@Servy, I just looked at the IL, and it is same. – Treponema

@Treponema That depends on what a is. – Brabble

@Servy, your answer made it clear, thanks. I have modified my answer as well, hopefully its correct now – Treponema

It's somewhat less wrong than it was before, but it still has several completely incorrect statements within it. – Brabble

Answer 2

That depends on what a is. a = a + 5 evaluates a twice. a += 5 evaluates a exactly once.

If a is an integer, that difference is likely not to matter in most cases, although not strictly all cases. If, for example, a is accessed from multiple threads then the exact types and windows for race conditions can differ.

On top of that, if evaluating the expression causes side effects it's the difference between those side effects being observed once versus being observed twice. That can, under certain circumstances, be a big deal, possibly affecting the correctness of the code, not just its speed.

Brabble