Я пытался оптимизировать свой код, чтобы сделать его немного более кратким и удобочитаемым, и надеялся, что я не буду хуже работать. Я думаю, что мои изменения, возможно, замедлили мое приложение, но это может быть просто в моей голове. Есть ли разница в производительности между:
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
}
Мое предпочтение читаемости было бы нулевым коалесцирующим оператором, я просто не хотел, чтобы он влиял на производительность.
IMHO, оптимизируйте для удобочитаемости и понимания - любой выигрыш в производительности во время исполнения, скорее всего, будет минимальным по сравнению с тем временем, когда вы вернетесь в реальный мир, когда вернетесь к этому коду через пару месяцев и попытаетесь понять, что черт возьми, вы делали в первую очередь.
Вы пытаетесь микро-оптимизировать здесь, и это, как правило, большой нет-нет. Если у вас нет аналитики производительности, которая показывает вам, что это проблема, ее даже не стоит менять.
Для общего использования правильный ответ - это то, что легче поддерживать.
Хотя, черт возьми, 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 занимают одинаковое количество времени, а это не так.
В любом случае, надеюсь, вы увидите, как оптимизация в этом микромасштабе может начать довольно быстро снижать отдачу.
Это, как говорится, в конце концов, для большинства случаев все, что легче читать и поддерживать в этом случае, является правильным ответом.
Если вы обнаружите, что делаете это в масштабе, где это оказывается неэффективным (а таких случаев мало и далеко друг от друга), то вам следует измерить, чтобы увидеть, какие из них имеют лучшую производительность, а затем выполнить эту конкретную оптимизацию.
Я думаю, что мои изменения, возможно, замедлились по моему приложению, но это может быть просто быть в моей голове.
Если вы на самом деле не измеряете производительность, все это в вашей голове и в режиме ожидания.
(Не выбирать вас, в частности, но неутешительно видеть вопрос после вопроса о производительности микро-оптимизации (как и многие ответы), которые не содержат слова "measure".)
Я подозреваю, что никакой разницы в производительности не будет.
Кроме того, я задаюсь вопросом, почему у вас возникнут какие-либо проблемы в отношении одного высказывания в другом случае в этом случае? Я имею в виду: влияние производительности (если оно должно быть), было бы минимальным. ИМХО, это будет своего рода микро-оптимизация, и это не должно стоить усилий.
Я бы выбрал инструкцию, которая наиболее читаема, наиболее понятна и не беспокоится о производительности, поскольку она будет иметь минимальное влияние (в данном случае).
В этом случае практически нет существенной разницы в производительности.
Когда разница в производительности незначительна, все это о читаемом коде.
Для обсуждения ради... если /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;
}
Вопрос о том, эффективен ли код уровня машины или код для чтения человеком. Поскольку мы делаем это более читаемым для нас, это заставляет машину выполнять сложные интерпретации кода и наоборот...