switch...case && if...else效率比较和优化

       以前一直都是在编程中,用switch...case和if....else混合一起使用。但是我个人的习惯是如果可以,我都会尽量使用switch语句进行条件判断。这只能说是个人习惯吧,以前也一直没有想很多,只是单纯的觉得比起if语句,使用switch可以简化我的输入,而且后面我在审视自己的代码的时候也会觉得比较容易读懂。

       最近小学期上课的时候,是一位公司的老师给我们上课,我观察了一下他的代码习惯,他倾向比较多的条件判断的时候,就使用switch,但是在小范围的条件判断中,他比较喜欢用if,我觉得这其中应该是有一定道理的,突然想起之前我在看《高性能javascript》的时候,作者也提出了这方面的优化。特此重新回顾了一下之前的书里的内容,结合网上大牛们的解释,做一次归纳总结吧。

使用if-else还是switch,最流行的方法是基于测试条件的数量来判断:条件数量越大,越倾向于使用switch而不是if-else。这通常归结于代码的易读性。这个观点认为,当条件较少时,if-else更易读,当条件较多时,使用switch更加易读。--《高性能javascript》

之后,我在维基百科也搜了一下switch_statement的有关资料,关于它的Compilation,维基百科作出了如下的解释:

维基百科_switch_statement关于汇编的部分截图

也就是说,在编译器中,它会将一系列的语句编译成分支表,然后在判断时,无需像if-else语句一样一个个进行逻辑判断,而是通过在case里的值,对值进行搜索,从而达到对搜索的优化。我也在知乎搜索了一下,但是发现不知道是不是我打开方式有问题,关于这方面的解释比较少,或者说。。问题太简单了。。。然后我找到了如下作者的回答(如果涉及侵权请联系我,我将立刻删除,谢谢。)

知友的回答

switch通过编译成一个分支表来达到优化的目的,我个人感觉是通过空间的代价来换取时间。说完了switch...case,现在我们再来对比一下if-else,没有对比就没有伤害。它和switch不同,if-else语句会对一个个条件按顺序进行查找,直到找到符合条件的"入口"。也因为这个特性,所以,当条件数量很大,它和switch的差距就慢慢显现出来了。

事实证明,大多数情况下switch比if-else允许得要快,但只有当数量条件很大时,才快得明显。当条件增加的时候,if-else性能负担增加的程度比switch明显得多。因此我们倾向于在条件数量比较少的情况下使用if-else,而在条件数量较大的时候使用switch,出于性能考虑,这是合理的。--《高性能javascript》

我个人的使用习惯是,当只有涉及到true||false的时候,我才会倾向于使用if-else语句,如果涉及到常数,或者数值的判断,我一般倾向于使用switch,事实证明,这种做法也是对的,出于对代码的可读性也好,出于性能考虑来说,我觉得我的使用习惯好像是正确的。

但是这本书中,有提及对if-else的优化:

最小化到达正确分之前所需要判断的条件数量,最简单的方式是将最可能的出现的条件放在首位........if-else语句应该总是按照最大概率到最小概率的顺序排序,或者,最小化条件判断的次数,使用嵌套的方式等。

但是我个人倾向于,代码的易读性,如果一味地使用嵌套,其实只会影响代码的可读性。


查找表【补充方案】

其实有时候优化条件语句的最佳方案是避免使用if-else和我switch,当有大量的离散数值时,查找表的优势就会慢慢体现出来,查找表这整个过程就变成了数据查询或者对象成员的查询了。

维基百科关于查找表的相关描述

当单个key和value之间存在有逻辑映射关系是,查找表的优势就会体现出来。一个查找表可以看做是一个数组或者一个对象,通过索引操作来取代逻辑运算,由于这样子的映射关系,可以让运行效率提高。

查找表最主要的优点是,不用任何条件判断语句,即使候选值增加,也不会有额外的性能开销。switch语句比较适合每个key都需要有独特对应一个或者一系列的动作的时候。

关于switch...case && if...else效率比较和优化就到这里了,一切共勉。本文仍存在很多不足,希望各位加以指点~谢谢。

# 补充于 2018-05-09

抛开我们所说的内存也好,效率也好,如果让我来总结这两个判断的一个异同点,我更倾向于用使用场景和你解释,我们更倾向于用 if 去判断连续的区间 用 switch 去判断离散分布的可能取值,也就是说:

if 比较适用的场景是 目标点 落在某一个区间 例如 90 < x <100 之类的

switch 比较适用的场景是 x = blue  .... x = red ..... 之类的处理场景


推荐阅读:

红黑联盟关于这方面的帖子

维基百科中文版-查找表

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,496评论 6 501
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,407评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,632评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,180评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,198评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,165评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,052评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,910评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,324评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,542评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,711评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,424评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,017评论 3 326
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,668评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,823评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,722评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,611评论 2 353

推荐阅读更多精彩内容