title: C# generated IL for ++ operator - when and why prefix/postfix notation is faster
body: <p>Since this question is about the increment operator and speed differences with prefix/postfix notation, I will describe the question very carefully lest Eric Lippert discover it and flame me!</p>
  
  <p>(further info and more detail on why I am asking can be found at <a href="http://www.codeproject.com/KB/cs/FastLessCSharpIteration.aspx?msg=3899456#xx3899456xx/">http://www.codeproject.com/KB/cs/FastLessCSharpIteration.aspx?msg=3899456#xx3899456xx/</a>)</p>
  
  <p>I have four snippets of code as follows:-</p>
  
  <p>(1) Separate, Prefix:</p>
  
  <pre><code>    for (var j = 0; j != jmax;) { total += intArray[j]; ++j; }
  </code></pre>
  
  <p>(2) Separate, Postfix:</p>
  
  <pre><code>    for (var j = 0; j != jmax;) { total += intArray[j]; j++; }
  </code></pre>
  
  <p>(3) Indexer, Postfix:</p>
  
  <pre><code>    for (var j = 0; j != jmax;) { total += intArray[j++]; }
  </code></pre>
  
  <p>(4) Indexer, Prefix:</p>
  
  <pre><code>    for (var j = -1; j != last;) { total += intArray[++j]; } // last = jmax - 1
  </code></pre>
  
  <p>What I was trying to do was prove/disprove whether there is a performance difference between prefix and postfix notation in this context (ie a local variable so not volatile, not changeable from another thread etc.) and if there was, why that would be.</p>
  
  <p>Speed testing showed that:</p>
  
  <ul>
  <li><p>(1) and (2) run at the same speed as each other.</p></li>
  <li><p>(3) and (4) run at the same speed as each other.</p></li>
  <li><p>(3)/(4) are ~27% slower than (1)/(2).</p></li>
  </ul>
  
  <p>Therefore I am concluding that there is no performance advantage of choosing prefix notation over postfix notation per se. However when the <em>Result of the Operation</em> is actually used, then this results in slower code than if it is simply thrown away.</p>
  
  <p>I then had a look at the generated IL using Reflector and found the following:</p>
  
  <ul>
  <li><p>The number of IL bytes is identical in all cases.</p></li>
  <li><p>The .maxstack varied between 4 and 6 but I believe that is used only for verification purposes and so not relevant to performance.</p></li>
  <li><p>(1) and (2) generated exactly the same IL so its no surprise that the timing was identical. So we can ignore (1).</p></li>
  <li><p>(3) and (4) generated very similar code - the only relevant difference being the positioning of a dup opcode to account for the <em>Result of the Operation</em>. Again, no surprise about timing being identical.</p></li>
  </ul>
  
  <p>So I then compared (2) and (3) to find out what could account for the difference in speed:</p>
  
  <ul>
  <li><p>(2) uses a ldloc.0 op twice (once as part of the indexer and then later as part of the increment).</p></li>
  <li><p>(3) used ldloc.0 followed immediately by a dup op.</p></li>
  </ul>
  
  <p>So the relevant IL for the incrementing j for (1) (and (2)) is:</p>
  
  <pre><code>// ldloc.0 already used once for the indexer operation higher up
  ldloc.0
  ldc.i4.1
  add
  stloc.0
  </code></pre>
  
  <p>(3) looks like this:</p>
  
  <pre><code>ldloc.0
  dup // j on the stack for the *Result of the Operation*
  ldc.i4.1
  add
  stloc.0
  </code></pre>
  
  <p>(4) looks like this:</p>
  
  <pre><code>ldloc.0
  ldc.i4.1
  add
  dup // j + 1 on the stack for the *Result of the Operation*
  stloc.0
  </code></pre>
  
  <p>Now (finally!) to the question:</p>
  
  <p>Is (2) faster because the JIT compiler recognises a pattern of <code>ldloc.0/ldc.i4.1/add/stloc.0</code> as simply incrementing a local variable by 1 and optimize it?
  (and the presence of a <code>dup</code> in (3) and (4) break that pattern and so the optimization is missed)</p>
  
  <p>And a supplementary:
  If this is true then, for (3) at least, wouldn't replacing the <code>dup</code> with another <code>ldloc.0</code> reintroduce that pattern?</p>