？：Operator Vs.如果聲明性能

我一直在試圖優化我的代碼，使其更簡潔和可讀，並希望我不會導致性能較差。我認爲我的改變可能會減慢我的應用程序，但它可能只是在我的腦海中。是否有任何之間的性能差異：？：Operator Vs.如果聲明性能

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 
}

我對可讀性的偏好將是空合併運算符，我只是不希望它影響性能。

來源

2009-02-13 Jon

恕我直言，針對可讀性和理解進行了優化 - 任何運行時性能增益可能都會相對於您在真實世界中花費幾個月時間回到此代碼所需的時間，並試圖瞭解首先你在做什麼。

來源

2009-02-13 19:12:34 PhilChuang

+13

當然，請記住，很多程序員可以閱讀？：語句與常規語句一樣快。在某些情況下，它們比使用沒有大括號的if/else語句更加清晰。 – NotMe 2009-02-13 19:49:07

我同意。這裏的許多帖子都是性能問題，詢問一些微小的調整（比+ + 1快++），這些都沒有關係。速度來自算法的複雜性：減少大量的內存拷貝，快速搜索容器，適當地散列。小的調整沒有性能影響。 – abelenky 2009-02-13 19:55:41

-1：雖然chublogga的觀點都是真實有效的，但是它們並沒有回答原來的問題。 OP是一個成年人，可以選擇自己的架構/可讀性，casperOne的答案對於具體的性能問題來說確實是一個更有趣和直接的答案。 – nezroy 2009-02-13 20:33:49

我懷疑不會有任何性能差異。

接下來，我想知道爲什麼在這種情況下你有任何關於支持另一個聲明的問題？我的意思是：性能影響（如果應該有的話）將是最小的。恕我直言，這將是一種微觀優化，應該不值得付出努力。
我會選擇最具可讀性，最清晰的語句，而不用擔心表現，因爲它會影響最小（在這種情況下）。

來源

2009-02-13 19:13:47

這種情況下幾乎沒有顯着的性能差異。

當性能差異可以忽略不計時，它全部是關於的可讀代碼。

來源

2009-02-13 19:17:45

您正在嘗試micro-optimize這裏，這通常是一個很大的禁忌。除非您有性能分析向您顯示這是一個問題，否則甚至不值得更改。

對於一般用途，正確的答案是任何更容易維護。

對於它的地獄雖然，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 coalescing operator，如果該值null，則執行6個語句，而使用switch執行4個操作。

如果不是null值，則空合併運算符執行四個操作而不是五個操作。

當然，這假定所有IL操作都花費相同的時間量，但情況並非如此。

無論如何，希望你能看到如何在這個微觀規模優化可以開始很快減少回報。

這就是說，最終，對於大多數情況來說，在這種情況下最容易閱讀和維護的是正確的答案。

如果您發現您在一個經證明效率不高的規模上（而且這些規模很少且很少），那麼您應該測量以查看哪個性能更好，然後進行特定的優化。

來源

2009-02-13 19:27:27 casperOne

我覺得我的變化可能已經放慢下來我的應用程序，但它可能只是在我的頭上。

除非你實際上測量性能，這一切都在你的頭部和遊資炒作。

（不要你挑選特別的，但它是如此令人失望的有關性能的微優化問題後的問題（以及許多問題的答案），不包含單詞「措施」）。

來源

2009-02-13 19:50:21 Brian

它是一個機器級代碼是否有效或人類可讀代碼的問題。因爲我們使它更容易讀懂，它使機器做複雜的解釋代碼，反之亦然...

來源

2013-05-11 11:28:47

爲了討論的緣故... if/then/else的運行速度與？：三元操作一樣快與單層開關/殼體聲明一樣快。

Here are some performance benchmarks with the C# code.

當你開始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; 
    }

來源

2014-09-14 13:53:23 WorkRelated

？：Operator Vs.如果聲明性能

回答

相關問題