C# generated IL for ++ operator-когда и почему префикс / постфикс быстрее

поскольку этот вопрос касается оператора приращения и различий в скорости с префиксной / постфиксной нотацией, я очень тщательно опишу вопрос, чтобы Эрик Липперт не обнаружил его и не поджег меня!

(более подробную информацию и более подробную информацию о том, почему я спрашиваю, можно найти по адресу http://www.codeproject.com/KB/cs/FastLessCSharpIteration.aspx?msg=3899456#xx3899456xx/)

у меня есть четыре фрагмента кода следующим образом: -

(1) отдельные, Приставка:

    for (var j = 0; j != jmax;) { total += intArray[j]; ++j; }

(2) Отдельно, Постфикс:

    for (var j = 0; j != jmax;) { total += intArray[j]; j++; }

(3) Индексатор, Постфикс:

    for (var j = 0; j != jmax;) { total += intArray[j++]; }

(4) Индексатор, Префикс:

    for (var j = -1; j != last;) { total += intArray[++j]; } // last = jmax - 1

то, что я пытался сделать, это доказать/опровергнуть, есть ли разница в производительности между префиксом и постфиксной нотацией в этом контексте (т. е. локальная переменная, настолько не изменчивая, не изменяемая из другого потока и т. д. а если бы и был, то почему бы и нет.

скорость испытания показали что:

• (1) и (2) работают с одинаковой скоростью.

• (3) и (4) работают с одинаковой скоростью.

• (3)/(4) являются ~27% медленнее, чем (1)/(2).

поэтому я заключаю, что нет никакого преимущества в производительности выбора префиксной нотации над постфиксной нотацией как таковой. Однако, когда результат работы фактически используется, то это приводит к более медленному коду, чем если бы он просто выбрасывался.

затем я посмотрел на сгенерированный IL с помощью рефлектора и нашел следующее:

• количество байтов IL идентично во всех случаях.

• The .maxstack варьировался от 4 до 6, но я считаю, что используется только для целей проверки и поэтому не имеет отношения к производительности.

• (1) и (2) генерируется точно такой же IL, поэтому его нет удивительно, что время совпадало. Поэтому мы можем игнорировать (1).

• (3) и (4) генерируется очень похожий код - единственное существенное различие заключается в позиционировании кода операции dup для учета результат работы. Опять же, неудивительно, что сроки совпадают.

поэтому я сравнил (2) и (3), чтобы узнать, что может объяснить разницу в скорости:

• (2) использует ldloc.0 op дважды (один раз как часть индексатора, а затем позже как часть приращения).

• (3) используется ldloc.0 сразу за ним следует DUP op.

таким образом, соответствующий IL для приращения j для (1) (и (2)):

// ldloc.0 already used once for the indexer operation higher up
ldloc.0
ldc.i4.1
add
stloc.0

(3) выглядит так:

ldloc.0
dup // j on the stack for the *Result of the Operation*
ldc.i4.1
add
stloc.0

(4) выглядит так:

ldloc.0
ldc.i4.1
add
dup // j + 1 on the stack for the *Result of the Operation*
stloc.0

теперь (наконец-то!) на вопрос:

это (2) быстрее, потому что JIT-компилятор распознает шаблон ldloc.0/ldc.i4.1/add/stloc.0 как просто увеличить локальную переменную на 1 и оптимизировать ее? (и присутствие dup в (3) и (4) сломайте этот шаблон, и поэтому оптимизация пропущена)

и дополнительного: Если это правда, то, по крайней мере, для (3) не будет заменять dup С другой ldloc.0 повторно ввести этот шаблон?