在c#中使用if/else和switch-case有什么显著的区别吗?

在c#中使用switch语句与使用if/else语句的优点/缺点是什么?除了代码的外观,我无法想象有这么大的区别。

是否有任何原因导致最终的IL或相关的运行时性能会有根本的不同?

相关:什么是更快,开关字符串或elseif类型?

122171 次浏览

实际上,switch语句更有效。编译器会将其优化为一个查找表,而使用if/else语句则不行。缺点是switch语句不能与变量值一起使用。

你不能:

switch(variable)
{
case someVariable:
break;
default:
break;
}

它必须是:

switch(variable)
{
case CONSTANT_VALUE:
break;
default:
break;
}

我认为,不只是c#,而是所有基于C的语言:因为切换仅限于常量,所以使用“跳转表”可以生成非常高效的代码。C用例实际上是一个很好的老式FORTRAN计算GOTO,但c#用例仍然是针对常量进行测试。

优化器不可能生成相同的代码。考虑,例如,

if(a == 3){ //...
} else if (a == 5 || a == 7){ //...
} else {//...
}

因为这些是复合布尔值,生成的代码必须计算一个值,然后短路。现在考虑一下

switch(a){
case 3: // ...
break;
case 5:
case 7: //...
break;
default: //...
}

这可以编译成

BTABL: *
B3:   addr of 3 code
B5:
B7:   addr of 5,7 code
load 0,1 ino reg X based on value
jump indirect through BTABL+x

因为你隐式地告诉编译器它不需要计算OR和相等测试。

编译器将把几乎所有内容都优化为相同的代码,只有微小的差异(Knuth,任何人?)

区别在于一个switch语句比串在一起的15个if else语句更简洁。

朋友不会让朋友叠加if-else语句。

通常它看起来会更好——也就是更容易理解发生了什么。考虑到性能上的好处最少,代码的视图是最重要的区别。

因此,如果if/else看起来更好,就使用它,否则使用switch语句。

我的计算机教授建议你不要切换语句,因为人们经常忘记断点或错误地使用它。我记不清他到底说了什么,但沿着这条线看了一些开创性的代码库,其中显示了switch语句的例子(几年前),其中也有大量的错误。

一般来说(考虑到所有语言和所有编译器),switch语句有时可能比if / else语句更有效,因为编译器很容易从switch语句生成跳转表。如果有适当的约束,也可以对if / else语句做同样的事情,但这要困难得多。

在c#的情况下,这也是正确的,但出于其他原因。

对于大量字符串,使用switch语句具有显著的性能优势,因为编译器将使用哈希表来实现跳转。

使用少量的字符串,两者之间的性能是相同的。

这是因为在这种情况下,c#编译器不会生成跳转表。相反,它生成等效于IF / ELSE块的MSIL。

有一个“switch statement”MSIL指令,当被触发时将使用一个跳转表来实现一个switch语句。但是,它只适用于整数类型(这个问题询问的是字符串)。

对于少量的字符串,编译器生成IF / ELSE块比使用哈希表更有效。

当我最初注意到这一点时,我做了一个假设,因为IF / ELSE块用于少量字符串,编译器对大量字符串做了相同的转换。

这是错误的。“IMA”好心地向我指出了这一点(嗯……他不怎么客气,但他是对的,我错了,这是最重要的部分)

我还对MSIL中缺少“switch”指令做了一个愚蠢的假设(我想,如果有一个switch原语,为什么他们不把它与哈希表一起使用,所以一定没有一个switch原语....). 这是错误的,而且我非常愚蠢。IMA再次向我指出了这一点。

我在这里更新是因为这是评分最高的帖子,也是公认的答案。

然而,我把它变成了社区维基,因为我认为我不应该因为犯错而获得REP。如果你有机会,请给ima的帖子投票。

题外话,但我经常担心(而且更经常看到)if/elseswitch语句在太多情况下变得太大。这些通常会损害可维护性。

常见的罪魁祸首包括:

  1. 在多个if语句中执行太多操作
  2. 案例陈述多得人类无法分析
  3. if求值中的条件太多,以至于不知道要寻找什么

修复:

  1. 提取到方法重构。
  2. 使用带有方法指针的Dictionary而不是大小写,或者使用IoC来增加可配置性。方法工厂也很有帮助。
  3. 提取条件到自己的方法

这实际上并没有回答您的问题,但考虑到编译版本之间的差异很小,我建议您以最能描述您的意图的方式编写代码。这样编译器不仅有更好的机会执行您所期望的操作,而且还会使其他人更容易维护您的代码。

如果您的意图是基于一个变量/属性的值来分支您的程序,那么switch语句最好地代表了这一意图。

如果你的意图是基于不同的变量/属性/条件来分支你的程序,那么If /else If链最能代表这个意图。

我承认cody在人们忘记break命令方面是正确的,但我几乎经常看到人们在犯{}错误的地方执行复杂的if块,因此应该在条件语句中的行却没有。这是我总是在if语句中包含{}的原因之一,即使其中只有一行。它不仅更容易阅读,而且如果我需要在条件语句中添加另一行,我也不会忘记添加它。

选择switch的三个原因:

  • 针对本机代码的编译器通常可以将switch语句编译为一个条件分支加上一个间接跳转,而__abc0序列则需要一个条件分支序列。根据案例的密度,如何高效地编写案例语句已成为众多学者研究的课题;一些链接来自lcc编译器页面。(Lcc有一个更创新的开关编译器。)

  • switch语句是互斥选项中的选项,而switch语法使这个控制流对程序员来说更加透明然后是if-then-else语句的一套。

  • 在一些语言中,包括ML和Haskell,编译器会检查你是否遗漏了任何大小写。我认为这个特性是ML和Haskell的主要优势之一。我不知道c#是否能做到这一点。

一个趣闻:在托尼·霍尔接受终身成就奖的演讲中,我听到他说,在他职业生涯中所做的所有事情中,有三件事是他最自豪的:

  • 发明快速排序
  • 发明switch语句(Tony称之为case语句)
  • 开始和结束他的工业生涯

无法想象没有switch的生活

SWITCH语句只在调试或兼容模式下产生与if相同的程序集。在发布版中,它将被编译成跳转表(通过MSIL 'switch'语句),即O(1)。

c#(不像许多其他语言)也允许打开字符串常量——这工作起来有点不同。为任意长度的字符串构建跳转表显然是不现实的,所以通常情况下,这样的切换将被编译成if堆栈。

但是如果条件的数量大到足以覆盖开销,c#编译器将创建一个HashTable对象,用字符串常量填充它,并在该表上进行查找,然后跳转。哈希表查找不是严格的O(1),并且有明显的常量代价,但是如果大小写标签的数量很大,它将比在if中比较每个字符串常量快得多。

总而言之,如果条件数量超过5个左右,则优先选择SWITCH而不是if,否则使用任何看起来更好的方法。

感兴趣的问题。这是几周前在工作中遇到的问题,我们通过编写一个示例片段并在.NET Reflector中查看它找到了答案(Reflector太棒了!!我喜欢它)。

这是我们的发现: 对于字符串以外的任何对象,有效的switch语句将作为switch语句编译到IL。然而,如果它是一个字符串,它在IL中被重写为IF /else IF /else。所以在我们的例子中,我们想知道switch语句如何比较字符串,例如区分大小写等,reflector很快给了我们一个答案。知道这一点很有用。< / p >

如果你想对字符串进行区分大小写的比较,那么你< em > < / em >可以使用switch语句,因为它比执行String更快。用if/else进行比较。(编辑:阅读什么是更快,开关字符串或elseif类型?一些实际的性能测试)然而,如果你想做一个不区分大小写的,那么最好使用if/else,因为结果代码不漂亮。

switch (myString.ToLower())
{
// not a good solution
}

最好的经验法则是使用switch语句,如果它是有意义的(认真的),例如:

  • 它提高了代码的可读性
  • 您正在比较一个值范围(float, int)或enum

如果您需要操作将值送入switch语句(创建一个用于切换的临时变量),那么您可能应该使用If /else控制语句。

更新:

将字符串转换为大写(例如ToUpper())实际上更好,因为与ToLower()相比,即时编译器显然可以做进一步的优化。这是一个微观优化,但在一个紧密的循环中,它可能是有用的。


补充一点:

为了提高switch语句的可读性,可以尝试以下方法:

  • 把最有可能的分支放在前面,即访问最多的分支
  • 如果它们都可能发生,按字母顺序列出,这样更容易找到它们。
  • 永远不要对剩下的最后一个条件使用默认的catch-all,这是懒惰的,并且会在以后的代码生命周期中导致问题。
  • 使用默认的catch-all来断言一个未知的条件,即使它几乎不可能发生。这就是断言的好处。

我刚刚注意到的是,你可以结合if/else和切换语句!在需要检查先决条件时非常有用。

if (string.IsNullOrEmpty(line))
{
//skip empty lines
}
else switch (line.Substring(0,1))
{
case "1":
Console.WriteLine(line);
break;
case "9":
Console.WriteLine(line);
break;
default:
break;
}

switch语句肯定比if else if语句快。有速度测试,已经提供了对它的黑黄蜂

http://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx

——看看吧

但很大程度上取决于你要考虑的可能性,但我尽量使用switch语句。

我没有看到其他人提出(明显的?)观点,即switch语句的假设效率优势取决于各种情况的可能性近似相等。在一个(或几个)值更有可能的情况下,if-then-else阶梯可以更快,通过确保首先检查最常见的情况:

举个例子:

if (x==0) then {
// do one thing
} else if (x==1) {
// do the other thing
} else if (x==2) {
// do the third thing
}

vs

switch(x) {
case 0:
// do one thing
break;
case 1:
// do the other thing
break;
case 2:
// do the third thing
break;
}

如果x在90%的时间为零,“If -else”代码的速度可以是基于开关的代码的两倍。即使编译器将“switch”转换为某种聪明的表驱动的goto,它仍然不会像简单地检查零那样快。

如果你只使用If或else语句基解使用比较?操作符

(value == value1) ? (type1)do this : (type1)or do this;

你可以在开关中执行或程序

switch(typeCode)
{
case TypeCode:Int32:
case TypeCode.Int64:
//dosomething here
break;
default: return;
}

根据这个链接,使用switch和if语句的IF vs Switch迭代测试的比较,就像对于1,000,000,000次迭代,开关语句所花费的时间=43.0秒 &by If语句 = 48.0秒

也就是每秒20833333次迭代,所以,我们真的需要更加关注吗,

附注:只是为了了解在少量条件下的性能差异。

我认为交换机比If条件更快 是否有这样一个程序:

写一个程序,输入任意数字(1- 99之间),并检查它在哪个槽a) 1- 9,然后槽1 b) 11 - 19,然后槽2 c) 21-29,然后槽3,直到89-99

然后,如果你有许多条件,但儿子切换情况下,你必须只是类型

开关(no /10)

case 0 = 1-9,case 1 = 11-19,以此类推

这将是如此简单

还有很多这样的例子!

switch语句基本上是相等的比较。键盘事件比switch语句有很大的优势,当代码易于编写和阅读时,if elseif语句会,缺少{括号}也可能会带来麻烦。

char abc;
switch(abc)
{
case a: break;
case b: break;
case c: break;
case d: break;
}
如果(theAmountOfApples > 5 &&“苹果的数量”比“保存你的苹果”要少 否则如果(theAmountOfApples大于10 || theAmountOfApples == 100)出售你的苹果。我不会写c#或c++,但我在学习java之前学过它,它们是很接近的语言

switch语句的一个可能的缺点是它缺乏多个条件。您可以为if (else)设置多个条件,但不能在一个交换机中使用不同条件的多个case语句。

Switch语句不适用于简单布尔方程/表达式范围以外的逻辑运算。对于布尔方程/表达式,它非常适合,但不适用于其他逻辑运算。

在If语句中,您可以更自由地使用可用的逻辑,但如果If语句变得笨拙或处理不当,则可读性会受到影响。

两者都有自己的位置,这取决于你所面对的环境。

我的意见。大多数情况下,如果性能不是标准,那么代码的可读性就更重要了。如果If /else语句的数量太多,则使用switch语句会更好。

在阅读了我面前所有的答案并浏览了所有的网页之后,我可以说switch case语句可以帮助您使您的代码看起来更整洁和易于管理。当我在我的项目中测试时,性能也比else if语句好,因为我必须检查超过10个用例(这可能听起来很奇怪!)