switch与ifelse的效率问题

来源:互联网 发布:策划相关书籍知乎 编辑:程序博客网 时间:2024/04/25 04:24
 

switch与ifelse的效率问题

标签: 编译器ubuntu汇编gcc优化扩展
 51073人阅读 评论(13) 收藏 举报
 分类:

switch与if..else 的执行的效率问题
 今天读一前辈的程序,发现其在串口中断里面为了分析协议的报文类型,在中断函数里面使用if..else语句。因为报文类型在现在看来只有两种,以后有可能还会增加,不确定。
 本人以为这样用有些不妥,为什么不用switch语句呢?猜想是不是因为效率方面的考虑呢,毕竟我们应该尽量是中断的处理代码更加简洁,时间效率更高才好。
 所以本人就查找相关资料,资料显示switch语句反而比ifelse的执行效率要高。
 下面来详细描述switch与ifelse的区别。
 switch...case与if...else的根本区别在于,switch...case会生成一个跳转表来指示实际的case分支的地址,而这个跳转表的索引号与switch变量的值是相等的。从而,switch...case不用像if...else那样遍历条件分支直到命中条件,而只需访问对应索引号的表项从而到达定位分支的目的。
具体地说,switch...case会生成一份大小(表项数)为最大case常量+1的跳表,程序首先判断switch变量是否大于最大case 常量,若大于,则跳到default分支处理;否则取得索引号为switch变量大小的跳表项的地址(即跳表的起始地址+表项大小*索引号),程序接着跳到此地址执行,到此完成了分支的跳转。
//

 

int main()
{
 unsigned int i,j;
 i=3;
 switch (i)
 {
  case 0:
  j=0;
  break;
  case 1:
  j=1;
  break;
  case 2:
  j=2;
  break;
  case 3:
  j=3;
  break;
  case 4:
  j=4;
  break;
  default:
  j=10;
  break;
 }


}

用gcc编译器,生成汇编代码(不开编译器优化)
 .file "shiyan.c"
 .text
.globl main
 .type main, @function
main:
 leal 4(%esp), %ecx
 andl $-16, %esp
 pushl -4(%ecx)
 pushl %ebp
 movl %esp, %ebp
 pushl %ecx
 subl $20, %esp
 movl $3, -8(%ebp)
 cmpl $4, -8(%ebp)
 ja .L2
 movl -8(%ebp), %eax
 sall $2, %eax
 movl .L8(%eax), %eax
 jmp *%eax
 .section .rodata
 .align 4
 .align 4
.L8:
 .long .L3
 .long .L4
 .long .L5
 .long .L6
 .long .L7
 .text
.L3:
 movl $0, -12(%ebp)
 jmp .L11
.L4:
 movl $1, -12(%ebp)
 jmp .L11
.L5:
 movl $2, -12(%ebp)
 jmp .L11
.L6:
 movl $3, -12(%ebp)
 jmp .L11
.L7:
 movl $4, -12(%ebp)
 jmp .L11
.L2:
 movl $10, -12(%ebp)
.L11:
 addl $20, %esp
 popl %ecx
 popl %ebp
 leal -4(%ecx), %esp
 ret
 .size main, .-main
 .ident "GCC: (Ubuntu 4.3.3-5ubuntu4) 4.3.3"
 .section .note.GNU-stack,"",@progbits


由此看来,switch有点以空间换时间的意思,而事实上也的确如此。
1.当分支较多时,当时用switch的效率是很高的。因为switch是随机访问的,就是确定了选择值之后直接跳转到那个特定的分支,但是if。。else是遍历所以得可能值,知道找到符合条件的分支。如此看来,switch的效率确实比ifelse要高的多。
2.由上面的汇编代码可知道,switch...case占用较多的代码空间,因为它要生成跳表,特别是当case常量分布范围很大但实际有效值又比较少的情况,switch...case的空间利用率将变得很低。
3.switch...case只能处理case为常量的情况,对非常量的情况是无能为力的。例如 if (a > 1 && a < 100),是无法使用switch...case来处理的。所以,switch只能是在常量选择分支时比ifelse效率高,但是ifelse能应用于更多的场合,ifelse比较灵活。

由此看来,上面前辈的中断处理程序中用switch是比较合适的,即节省了时间,而且对于以后程序的扩展也是很方便。因为报文类型这个值基本上都是用整形常量来表示的。

14
1
 
 

  相关文章推荐
  •  if else 和 switch的效率
  •  【免费】深入理解Docker内部原理及网络配置--王渊命
  •  switch-case和if-else的效率比较
  •  SDCC 2017之区块链技术实战线上峰会--蔡栋
  •  switch...case和if...else效率比较
  •  php零基础到项目实战
  •  R语言︱函数使用技巧(循环、if族/for、switch、repeat、ifelse、stopifnot)
  •  C语言及程序设计入门指导
  •  OpenJDK源码研究笔记(十一):浅析Javac编译过程中的抽象语法树(IfElse,While,Switch等语句的抽象和封装)
  •  Android入门实战
  •  if...else与switch...case的执行效率问题
  •  5天搞定深度学习框架Caffe
  •  if...else if...和switch...case...执行效率
  •  switch case与if else执行效率分析
  •  关于if(){}else(){} 和 switch() case的执行效率
  •  switch...case和if...else效率比较
查看评论
8楼 chair00man 2017-05-06 11:26发表 [回复]
如果有1000个可能性,每一个可能性都可能被命中,且从上往下刷新的。用哪个好?或者还有其他选择?
7楼 前行的路- 2016-05-11 10:22发表 [回复]
写的很好,大神我可以转载下吗?再对她进行一些补充
6楼 Gnorth 2015-10-28 17:53发表 [回复]
switch case 有时候,是可以优化执行的,在vc++中是如此,gcc我不清楚,以x86汇编为例:

jmp dword ptr [xxxxxxxx + eax * 4]

其中xxxxxxxx 是个常数,在代码段所在的模块中分配,eax就是case值对应的索引,但必须有个前提是,case数值需要是连续的数值,这样代码执行时利用一次寻址来代替所有比较。
5楼 liuhuai1234 2015-08-12 17:59发表 [回复]
大家对swith...case 和指针数组的效率做比较,有什么看法。把每个case的内容定义成一个指针函数,把每个case值作为数组的下标,这样数组的性能和switch..case的性能,那个性能比较好。
4楼 ZhouYates 2015-07-29 18:06发表 [回复]
switch也并不总是那么好,因为每次计算会有一个二次查表过程。
具体需要看应用场景,举个例子:对于网络层的协议分析,%99可能都是IP协议,因此基本上会在第一个if时就命中,只有一次计算。
更多的优化措施还有likely/unlikely。
总结来说:对于分支较多或分布相对均匀的情况,使用switch可以提高效率;对于分支较少或分布不均匀的情况,使用if...if else更好。
3楼 逍遥随风翼 2015-03-19 21:56发表 [回复]
看来LZ连基本的选择语句内涵都没弄清楚。
按你的逻辑ifelse可以完全退出了,事实完全不是。
switch只能作用于那些同一类型的数值化选择,使用范围很窄;事实上if语句用的更多。
究其原因就是很多连续判断的种类不一样,也无法数值化,故而根本不能用switch。
就比如写一个键盘按钮与鼠标都可以对屏幕进行移动的操作,LZ可以写出switch的判断吗??当然,你可以先if下到底是键盘事件还是鼠标事件再来用switch。
发文章之前先思考一下吧。
Re: Christopher_ 2017-05-19 15:40发表 [回复]
他根本没看完
Re: suxing_ing 2015-04-23 01:35发表 [回复]
回复ymf007:先看清楚文章再说话
2楼 guobojj 2013-01-10 19:01发表 [回复]
楼主好像弄反了吧,开始时候说前辈用的是if...else,最后总结时候又说前辈用的是switch...case,应该是switch...case效率高吧??
Re: dee8756 2013-03-18 11:45发表 [回复]
回复guobojj:楼主的意思是,前辈的那条语句应该要用switch会比较好
1楼 匿名用户 2010-03-24 19:23发表 [回复]
[e10]