Will my compiler ignore useless code?

Question

I've been through a few questions over the network about this subject but I didn't find any answer for my question, or it's for another language or it doesn't answer totally (dead code is not useless code) so here's my question:

Is (explicit or not) useless code ignored by the compiler?

For example, in this code:

double[] TestRunTime = SomeFunctionThatReturnDoubles;
// A bit of code skipped
int i = 0;
for (int j = 0; j < TestRunTime.Length; j++)
{

}
double prevSpec_OilCons = 0;

will the for loop be removed?

I use .net4.5 and vs2013

---

The background is that I maintain a lot of code ^{(that I didn't write)} and I was wondering if useless code should be a target or if I could let the compiler take care of that.

Answer 1

I've made a little form to test it according to a few answerers ideas about using long.MaxValue, here's my reference code:

public Form1()
{
    InitializeComponent();
    Stopwatch test = new Stopwatch();
    test.Start();
    myTextBox.Text = test.Elapsed.ToString();
}

and here's the code with kinda useless code:

public Form1()
{
    InitializeComponent();
    Stopwatch test = new Stopwatch();
    test.Start();
    for (int i = 0; i < int.MaxValue; i++)
    {
    }
    myTextBox.Text = test.Elapsed.ToString();
}

You'll remark that I used int.MaxValue instead of long.MaxValue, I didn't want to spend the year day on this one.

As you can see:

---------------------------------------------------------------------
|                   |   Debug               |   Release             |
---------------------------------------------------------------------
|Ref                |   00:00:00.0000019    |   00:00:00.0000019    |
|Useless code       |   00:00:05.3837568    |   00:00:05.2728447    |
---------------------------------------------------------------------

The code isn't optimized. Hang on a bit, I'll try with some int[] to test int[].Lenght:

public Form1()
{
    InitializeComponent();
    int[] myTab = functionThatReturnInts(1);

    Stopwatch test = new Stopwatch();
    test.Start();
    for (int i = 0; i < myTab.Length; i++)
    {

    }
    myTextBox.Text = test.Elapsed.ToString();
}
public int[] functionThatReturnInts(int desiredSize)
{
    return Enumerable.Repeat(42, desiredSize).ToArray();
}

And here's the results:

---------------------------------------------
|   Size            |   Release             |
---------------------------------------------
|             1     |   00:00:00.0000015    |
|           100     |   00:00:00            |
|        10 000     |   00:00:00.0000035    |
|     1 000 000     |   00:00:00.0003236    |
|   100 000 000     |   00:00:00.0312673    |
---------------------------------------------

So even with arrays, it doesn't get optimized at all.

Answer 2

In your loop there are two an operation implicit in each iteration. An increment:

j++;

and comparison

j<TestRunTime.Length;

So, the loop is not empty although it looks like it is. There is something being executed at the end and this is not ignored by the compiler of course.

This happens also in other loops.

Answer 3

It won't be ignored. However, when you get to IL there will be a jump statement, so the for will run as if it was an if statement. It will also run the code for ++ and length, as @Fleve mentioned. It will just be extra code. For readability sake, as well as to keep with code standards I would remove the code if you don't use it.

Answer 4

Well, your variables i and prevSpec_OilCons, if not used anywhere will be optimized away, but not your loop.

So if your code looks like:

static void Main(string[] args)
{
    int[] TestRunTime = { 1, 2, 3 };
    int i = 0;
    for (int j = 0; j < TestRunTime.Length; j++)
    {

    }
    double prevSpec_OilCons = 0;
    Console.WriteLine("Code end");
}

under ILSpy it will be:

private static void Main(string[] args)
{
    int[] TestRunTime = new int[]
    {
        1,
        2,
        3
    };
    for (int i = 0; i < TestRunTime.Length; i++)
    {
    }
    Console.WriteLine("Code end");
}

Since the loop has couple of statements, like comparison and increment, it could be used for implementing somewhat short delay/wait period. (although not a good practice to do so).

Consider the following loop, which is an empty loop, but it will take a lot of time to get executed.

for (long j = 0; j < long.MaxValue; j++)
{

}

The loop in your code, is not a dead code, as far as dead code is concerned, the following is a dead code, and will be optimized away.

if (false)
{
    Console.Write("Shouldn't be here");
}

The loop, will not even be removed by the .NET jitters. Based on this answer

Answer 5

Is (explicit or not) useless code ignored by the compiler?

You can't easily determine it's useless, so the compiler can't either. The getter of TestRunTime.Length can have side-effects, for example.

The background is that I maintain a lot of code (that I didn't write) and I was wondering if useless code should be a target

Before you refactor a piece of code, you have to verify what it does in order to be able to change it and say afterwards it still has the same result. Unit tests are a great way of doing this.

Answer 6

The JIT is basically capable of removing dead code. It is not very thorough. Dead variables and expressions are reliably killed. That is an easy optimization in SSA form.

Not sure about control flow. If you nest two loops only the inner one will be deleted I remember.

If you want to find out for sure what is deleted and what not look at the generated x86 code. The C# compiler does very few optimizations. The JIT does a few.

The 4.5 32 and 64 bit JITs are different code bases and have different behavior. A new JIT (RyuJIT) is upcoming that in my testing generally does worse, sometimes better.

Answer 7

Obviously your compiler will not ignore useless code, but analyse it carefully and then try to remove it, if it performs optimisations.

In your case, the first interesting thing is whether the variable j is used after the loop or not. The other interesting thing is TestRunTime.Length. The compiler will look at it and check whether it always returns the same result, and if yes whether it has any side effects, and if yes whether calling it once has the same side effect in total as calling it repeatedly.

If TestRunTime.Length has no side effect and j is not used then the loop is removed.

Otherwise, if calling TestRunTime.Length repeatedly has more side effects than calling it once, or if repeated calls return different values, then the loop must be executed.

Otherwise, j = max (0, TestRunTime.Length).

Next, the compiler can determine whether the assignment TestRunTime.Length is needed. It may be replaced with code that just determines what TestRunTime.Length would be.

Then of course your compiler might not try any fancy optimisations, or the language rules might be so that it cannot determine these things, and you are stuck.

Answer 8

For the most part, you shouldn't worry about proactively removing useless code. If you run into performance issues, and your profiler says that some useless code is eating your clock cycles, then go nuclear on it. However, if the code truly does nothing and has no side effects, then it'll probably have little impact on running time.

That said, most compilers are not required to perform any optimizations, so relying on compiler optimizations is not always the smartest option. In many cases though, even a useless spin loop can execute pretty fast. A basic spinlock that loops one million times would compile into something like mov eax, 0 \ inc eax \ cmp eax, 1000000 \ jnz -8. Even if we discounted on-CPU optimizations, that's only 3 cycles per loop (on a recent RISC style chip) since there is no memory access, so there won't be any cache invalidation. On a 1GHz CPU, that's only 3,000,000/1,000,000,000 seconds, or 3 milliseconds. That would be a pretty significant hit if you tried running it 60 times a second, but in many cases, it probably won't even be noticeable.

A loop like the one I described would almost definitely be peephole optimized to mov eax 1000000, even in a JIT environment. It would likely be optimized further than that, but given no other context, that optimization is reasonable and would cause no ill effects.

tl;dr: If your profiler says that dead/useless code is using a noticeable amount of your run-time resources, remove it. Don't go on a witch hunt for dead code though; leave that for the rewrite/massive refactor down the line.

Bonus: If the code generator knew that eax wasn't going to be read for anything other than the loop condition and wanted to retain the spinlock, it could generate mov eax, 1000000 \ dec eax \ jnz -3 and reduce the penalty of the loop by a cycle. Most compilers would just remove it entirely though.

Answer 9

The loop can't be removed, the code is not dead, for instance:

  // Just some function, right?
  private static Double[] SomeFunctionThatReturnDoubles() {
    return null;
  }

  ...
  double[] TestRunTime = SomeFunctionThatReturnDoubles();
  ...
  // You'll end up with exception since TestRunTime is null
  for (int j = 0; j < TestRunTime.Length; j++)
  {
  }
  ...

Usually, compiler just can't predict all possible outcomes of SomeFunctionThatReturnDoubles and that's why it preserves the loop