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

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

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
}

Мое предпочтение читаемости было бы нулевым коалесцирующим оператором, я просто не хотел, чтобы он влиял на производительность.

Ответ 1

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

Ответ 2

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

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

Хотя, черт возьми, 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 значения, оператор объединения нулей выполняет четыре операции против пяти операций.

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

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

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

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

Ответ 3

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

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

(Не выбирать вас, в частности, но неутешительно видеть вопрос после вопроса о производительности микро-оптимизации (как и многие ответы), которые не содержат слова "measure".)

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

Для обсуждения ради... если /then/else работает так же быстро, как и?: трехмерная операция так же быстро, как одноуровневый оператор switch/case.

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

Это только тогда, когда вы начинаете получать 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;
    }

Ответ 7

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