Соответствует ли размер скомпилированного кода в MSIL скорости кода?

Question

Я играл с различными типами операций с собственным кодом в Visual Basic, а затем проверял код с помощью Reflector, чтобы увидеть, какой тип MSIL создается.Например, мне было интересно, в одной строке If-Then-Else, отличной от If-Then-Else, разделенной на несколько строк, то есть.

If x > y Then x Else y

против

If x > y Then
    x
Else
    y
End If

Оказывается, эти два компиляции в один и тот же MSIL.Тогда я задумался о новом операторе If , похожем на старую функцию IIf .Важно отметить, что на самом деле IIf является функцией и поэтому накладывает накладные расходы на вызов функции, поэтому, хотя она и выглядит лаконичной, она имеет свои недостатки.Кроме того, он оценивает как TruePart, так и FalsePart перед возвратом значения, т.е.не закорачивает, поэтому может иметь неожиданное поведение.Итак, я буду придерживаться оператора If .

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

If(x > y, x, y)

Произведенный MSIL намного меньше и, казалось бы, более эффективен.Что приводит меня к вопросу в теме.

Соответствует ли размер скомпилированного кода в MSIL скорости кода?

Answer 1

Что касается необработанного времени выполнения (исключая накладные расходы на загрузку и JIT-компиляцию кода), корреляции нет.

Циклы являются основным примером компактного кода, который может выполняться в течение очень длительного времени.Вы можете написать очень короткий однострочник, который никогда не завершится:

void VerySmallAndNeverTerminates() { for (;;); }

Вы также можете написать код настолько сложный и длинный, если компилятор позволит, чтобы (как только JIT-компилятор закончил с ним), возвращался почти мгновенно,Вам нужно только быть умнее, чем компилятор:

void VeryBigAndFast(int n) {
    if (Math.Abs(n) < 0) {
        // Write lots of code here. What doesn't matter,
        // since it will never be executed. The compiler
        // probably isn't smart enough to know that.
    }
}

Таким образом, больше не обязательно означает медленнее, хотя компилятору кода Just-In-Time, вероятно, потребуется больше времени, и этозагрузка кода может занять больше времени, если его нет в памяти.

Единственный способ определить, какая из двух альтернатив быстрее, - это измерить.И в большинстве случаев это все равно не имеет значения.

Answer 2

Нет.Типичным контрпримером является развертывание цикла, которое набирает скорость за счет размера.

Answer 3

На очень упрощенном уровне выполнение большего количества инструкций займет больше времени, чем меньше, но вы не можете просто сказать, что размер скомпилированного кода соответствует скорости.

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

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

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