?: Оператор Vs. Если заявление производительности

Question

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

Command.Parameters["@EMAIL"].Value = email ?? String.Empty;

и

Command.Parameters["@EMAIL"].Value = (email == null) ? String.Empty: email;

и

if (email == null)
{
    Command.Parameters["@EMAIL"].Value = String.Empty
}
else
{
    Command.Parameters["@EMAIL"].Value = email
}

Моим предпочтением для удобочитаемости будет оператор объединения нулей, я просто не хотел, чтобы это влияло на производительность.

Answer 1

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

Для общего использования правильный ответ - это то, что легче поддерживать.

Хотя, черт возьми, IL для оператора объединения нулей:

L_0001: ldsfld string ConsoleApplication2.Program::myString
L_0006: dup 
L_0007: brtrue.s L_000f
L_0009: pop 
L_000a: ldsfld string [mscorlib]System.String::Empty
L_000f: stloc.0 

И IL для коммутатора:

L_0001: ldsfld string ConsoleApplication2.Program::myString
L_0006: brfalse.s L_000f
L_0008: ldsfld string ConsoleApplication2.Program::myString
L_000d: br.s L_0014
L_000f: ldsfld string [mscorlib]System.String::Empty
L_0014: stloc.0 

Для нулевого оператора объединения , если значение равно null, то выполняются шесть операторов, тогда как с switch выполняются четыре операции.

В случае значения, отличного от null, оператор слияния NULL выполняет четыре операции против пяти операций.

Конечно, это предполагает, что все операции IL занимают одинаковое количество времени, а это не так.

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

Это, как говорится, в конце концов, для большинства случаев все, что легче всего читать и поддерживать в этом случае, является правильным ответом.

Если вы обнаружите, что делаете это в масштабе, где это оказывается неэффективным (а таких случаев мало и далеко друг от друга), то вам следует измерить, чтобы выяснить, какие из них имеют лучшую производительность, а затем провести конкретную оптимизацию. *

Answer 2

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

Answer 3

Я думаю, что мои изменения могли замедлиться вниз мое приложение, но это может просто быть в моей голове.

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

(Не особо обращайте на вас внимание, но так досадно видеть вопрос за вопросом о микрооптимизации производительности (а также о многих ответах), в которой нет слова «мера».)

Answer 4

Практически нет существенной разницы в производительности в этом случае.

Когда разница в производительности незначительна, это все о читаемый код .

Answer 5

Я подозреваю, что разницы в производительности не будет.

Кроме того, мне интересно, почему в этом случае у вас есть какие-то опасения по поводу предпочтения одного утверждения другому? Я имею в виду: влияние на производительность (если таковое должно быть) будет минимальным. ИМХО, это будет своего рода микрооптимизация, и она не должна стоить усилий.
Я бы выбрал утверждение, которое является наиболее читабельным, наиболее понятным и не беспокоиться о производительности, поскольку оно будет иметь минимальное влияние (в данном случае).

Answer 6

Для обсуждения ... если / then / else выполняется так же быстро, как троичная операция?: Так же быстро, как оператор уровня / переключатель одного уровня.

Вот некоторые тесты производительности с кодом C #.

Только когда вы начинаете получать 2-3 уровня глубины, если заявления о том, что производительность начинает сильно снижаться. То есть что-то вроде этого нелепого примера:

switch (x % 3)
    {
        case 0:
            switch (y % 3)
            {
                case 0: total += 3;
                    break;
                case 1: total += 2;
                    break;
                case 2: total += 1;
                    break;
                default: total += 0;
                    break;
            }
            break;
        case 1:
            switch (y % 3)
            {
                case 0: total += 3;
                    break;
                case 1: total += 2;
                    break;
                case 2: total += 1;
                    break;
                default: total += 0;
                    break;
            }
            break;
    case 2:
            switch (y % 3)
            {
                case 0: total += 3;
                    break;
                case 1: total += 2;
                    break;
                case 2: total += 1;
                    break;
                default: total += 0;
                    break;
            }
            break;
    default:
        switch (y % 3)
        {
            case 0: total += 3;
                break;
            case 1: total += 2;
                break;
            case 2: total += 1;
                break;
            default: total += 0;
                break;
        }
        break;
    }

Answer 7

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