？:操作员与 如果声明表现

我一直在尝试优化我的代码,使其更简洁和可读,并希望我没有造成更差的性能.我认为我的更改可能会减慢我的应用程序,但它可能只是在我脑海中.两者之间是否有任何性能差异:

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> casperOne..：

---

你正试图在这里进行微观优化,这通常是一个很大的禁忌.除非你有性能分析向你展示这是一个问题,否则它甚至都不值得改变.

对于一般用途,正确的答案是更容易维护.

尽管如此,空合并运算符的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操作都花费相同的时间,但事实并非如此.

无论如何,希望你能看到这种微观规模的优化如何能够很快开始减少回报.

话虽这么说,但在大多数情况下,在这种情况下最容易阅读和维护的是正确的答案.

如果您发现这样做会导致效率低下(并且这些情况很少且很少),那么您应该测量哪个具有更好的性能,然后进行特定的优化.

---

方法调用很可能会被内联,而不是它的jitted吗？

2> PhilChuang..：

---

恕我直言,优化可读性和理解 - 任何运行时性能提升可能会比你在几个月内回到这个代码时在现实世界中花费的时间最少,并试图理解你到底是什么做的第一个.

---

当然,请记住很多程序员都可以阅读？:语句与常规if语句一样快.在某些情况下,它们比使用没有大括号的if/else语句更清晰.

---

-1:虽然chublogga的分数都是真实有效且措辞很好,但它们并没有回答原始问题.OP是一个成年人,可以做出自己的架构/可读性选择,而casperOne的答案实际上是对特定性能问题的一个更有趣和直接的答案.

3> Brian..：

---

我认为我的更改可能会减慢我的应用程序,但它可能只是在我脑海中.

除非你实际上是在衡量绩效,否则这一切都在你的头脑和闲置的猜测之中.

(特别是不要选择你,但是对于不包含单词"measure"的性能微观优化(以及许多答案)的问题,我们会非常失望.)

4> Frederik Ghe..：

---

我怀疑不会有任何性能差异.

接下来,我想知道为什么在这种情况下你会有什么担心赞成一个声明呢？我的意思是:性能影响(如果应该有的话)将是最小的.恕我直言,这将是一种微观优化,它不值得努力.
我会选择最可读,最清晰且不担心性能的语句,因为它的影响很小(在这种情况下).

5> Chris Ballan..：

---

在这种情况下几乎没有显着的性能差异.

当性能差异可以忽略不计时,它就是可读代码.