if else 和 switch的效率

简介: switch在判断分支时,没有判断所有的可能性,而是用一个静态表来解决这个问题,所以速度要比if-else快。 但是,switch对较复杂的表达式进行判断,所以当我们需要判断一些简单数值时,用switch较好。

switch在判断分支时,没有判断所有的可能性,而是用一个静态表来解决这个问题,所以速度要比if-else快。 
但是,switch对较复杂的表达式进行判断,所以当我们需要判断一些简单数值时,用switch较好。

 

下面是转载的内容,我看说的很有道理

 

switch和if-else相比,由于使用了Binary Tree算法,绝大部分情况下switch会快一点,除非是if-else的第一个条件就为true. 
说实话  我也没有深入研究过这个问题的根源 
只是在实际开发中  没有人会去用很多很多else if的 
都是用 switch case 的  后者比较清晰  给人感觉就是一个脑子很清楚的人写出来的东西 
至于效率的本质  就让大企鹅去操心吧 

编译器编译switch与编译if...else...不同。不管有多少case,都直接跳转,不需逐个比较查询。 

昨天发现了一本叫做CSAPP的书,终于找到了关于switch问题的解答。 
这是一段C代码: 
/* $begin switch-c */ 
int switch_eg(int x) 

    int result = x; 

    switch (x) { 

    case 100: 
    result *= 13; 
    break; 

    case 102: 
    result += 10; 
    /* Fall through */ 

    case 103: 
    result += 11; 
    break; 

    case 104: 
    case 106: 
    result *= result; 
    break; 

    default: 
    result = 0;       
    } 

    return result; 

/* $end switch-c */ 

用GCC汇编出来的代码如下: 
    .file    "switch.c" 
    .version    "01.01" 
gcc2_compiled.: 
.text 
    .align 4 
.globl switch_eg 
    .type     switch_eg,@function 
switch_eg: 
    pushl %ebp 
    movl %esp,%ebp 
    movl 8(%ebp),%edx 
    leal -100(%edx),%eax 
    cmpl ,%eax 
    ja .L9 
    jmp *.L10(,%eax,4) 
    .p2align 4,,7 
.section    .rodata 
    .align 4 
    .align 4 
.L10: 
    .long .L4 
    .long .L9 
    .long .L5 
    .long .L6 
    .long .L8 
    .long .L9 
    .long .L8 
.text 
    .p2align 4,,7 
.L4: 
    leal (%edx,%edx,2),%eax 
    leal (%edx,%eax,4),%edx 
    jmp .L3 
    .p2align 4,,7 
.L5: 
    addl ,%edx 
.L6: 
    addl ,%edx 
    jmp .L3 
    .p2align 4,,7 
.L8: 
    imull %edx,%edx 
    jmp .L3 
    .p2align 4,,7 
.L9: 
    xorl %edx,%edx 
.L3: 
    movl %edx,%eax 
    movl %ebp,%esp 
    popl %ebp 
    ret 
.Lfe1: 
    .size     switch_eg,.Lfe1-switch_eg 
    .ident    "GCC: (GNU) 2.95.3 20010315 (release)" 

在上面的汇编代码中我们可以很清楚的看到switch部分被分配了一个连续的查找表,switch case中不连续的部分也被添加上了相应的条目,switch表的大小不是根据case语句的多少,而是case的最大值的最小值之间的间距。在选择相应 的分支时,会先有一个cmp子句,如果大于查找表的最大值,则跳转到default子句。而其他所有的case语句的耗时都回事O(1)。 

相比于if-else结构,switch的效率绝对是要高很多的,但是switch使用查找表的方式决定了case的条件必须是一个连续的常量。而if-else则可以灵活的多。 


可以看到if-else只是单纯地一个接一个比较,效率比较低 

可以看出,switch的效率一般比if-else高 


switch   效率高,     从汇编代码可以看出来   
switch   只计算一次值   然后都是test   ,   jmp,     
if...else   是每个条件都要计算一遍的.  

switch的效率与分支数无关   
 当只有分支比较少的时候,if效率比switch高(因为switch有跳转表)   
 分支比较多,那当然是switch

相关文章
|
JSON Java API
GSON 泛型对象反序列化解决方案
GSON 泛型对象反序列化解决方案
1109 0
|
12月前
|
存储 人工智能 数据可视化
从零构建能自我优化的AI Agent:Reflection和Reflexion机制对比详解与实现
AI能否从错误中学习?Reflection与Reflexion Agent通过生成-反思-改进循环,实现自我优化。前者侧重内容精炼,后者结合外部研究提升准确性,二者分别适用于创意优化与知识密集型任务。
2176 9
从零构建能自我优化的AI Agent:Reflection和Reflexion机制对比详解与实现
|
前端开发 JavaScript 测试技术
android做中大型项目完美的架构模式是什么?是MVVM吗?如果不是,是什么?
在 Android 开发中,选择合适的架构模式对于构建中大型项目至关重要。常见的架构模式有 MVVM、MVP、MVI、Clean Architecture 和 Flux/Redux。每种模式都有其优缺点和适用场景,例如 MVVM 适用于复杂 UI 状态和频繁更新,而 Clean Architecture 适合大型项目和多平台开发。选择合适的架构应考虑项目需求、团队熟悉度和可维护性。
671 6
|
存储 运维 监控
国际MSP巨头是怎么玩转Zabbix的?
某国际MSP(托管服务提供商)采用Zabbix为核心,打造“监控-预警-自愈”闭环体系,解决全平台监控、自动化修复和成本控制挑战。通过与事件驱动型Ansible深度集成,实现故障自动修复和智能告警分流,将运维从救火模式转变为预防性管理。这套方案几乎零软件成本,大幅提升效率与员工满意度,助力MSP实现服务稳定性和生产力的飞跃。Zabbix以领先技术赋能企业,推动运维进入主动防御新时代。
324 7
|
人工智能 搜索推荐 数据挖掘
2024中国CRM排行榜
中国的 CRM 发展经历了从萌芽到快速成长的过程。早期主要依赖手工记录,20 世纪 50 年代商用计算机普及后,CRM 开始发挥作用。90 年代末,CRM 理念引入中国,市场由国外厂商主导。2004 年后,SaaS 模式兴起,但因企业接受度低、成本高而遇到挑战。2008 年,移动互联网推动 CRM 快速发展,2015 年 SaaS CRM 迎来爆发。如今,市场规模不断扩大,预计 2024 年将突破 250 亿元。主要品牌如销售易、Zoho、SAP 和微软 Dynamics 365 等,各具特色,满足不同企业需求。
2024中国CRM排行榜
|
存储 运维 安全
无影云电脑初体验
#我与无影初体验 #无影使用感受
73544 91
无影云电脑初体验
|
域名解析 编解码 负载均衡
【域名解析DNS专栏】域名解析中的EDNS扩展:提升DNS协议灵活性
【5月更文挑战第27天】EDNS(Extension Mechanisms for DNS)是为了解决传统DNS协议在复杂网络环境下的灵活性和扩展性问题而诞生的技术。它允许在DNS请求和响应中添加额外选项,提高查询效率,支持更大数据范围,增强安全性,并实现负载均衡和故障转移。通过在DNS消息中包含EDNS部分,客户端和服务器能交换更多信息,实现更复杂的逻辑。EDNS的使用示例代码展示了如何在Python中创建和处理EDNS选项。随着技术进步,EDNS将在域名解析领域扮演更重要角色。
1407 1
|
SQL Java 数据库连接
MyBatis SQL 批量更新(代码➕案例)
MyBatis SQL 批量更新(代码➕案例)
1924 0
|
消息中间件 监控 负载均衡
深入解析Kafka中的Lag现象
深入解析Kafka中的Lag现象
2002 0