调度表与交换机语句

时间:2016-02-23 06:43:24

标签: javascript

我试图了解调度表如何优于switch语句,假设我们有以下两个场景来处理相同的功能

切换声明

swtich(value){
   case 'a':
     fun1(value);
     break;

   case 'b':
     fun2(value);
     break;

   case 'c':
     fun3(value);
     break;

}

现在上面的switch语句可以继续增长并且可能变得杂乱无章,因此我们可以使用“调度表”来替代对象

派遣表

function dispatching(value){
    var list = {
       'a': fun1,
       'b': fun2,
       'c': fun3
    }

   return list[value]();
}

如果我要遵循上述功能,则对象列表在调用时不会通过其所有属性。我看到它如何使其可维护,但它的性能有所改善?

2 个答案:

答案 0 :(得分:4)

  

......但它的性能有所改善吗?

重要的可能性极小,非常小。如果它对您正在做的事情可能很重要,那么最好的办法就是使用代表性选项对其进行编码,并对其进行测试,例如使用http://jsperf.com进行测试。

但是,在对象上查找属性可能比等效switch更快。要处理switch,引擎需要按源代码顺序测试案例并在第一场比赛时停止; JavaScript switch实际上只是if...else if...的另一种形式。 (当然,如果引擎可以看到选项是互斥的,那么它可以优化该过程。)相比之下,现代JavaScript引擎是即时编译器并在运行时生成类;按字符串名称(list[value])查找属性的速度不如名称文字(list.a)的属性查找速度快,但它仍然非常快,因为引擎不必按顺序进行并且可以查看使用平衡哈希树或类似的方法启动属性。

然而另一种说法是:如果你的函数很短,引擎可能能够在switch版本中内联它们(例如,在封面下,将函数代码移到{{1}中而不是实际进行函数调用),这可以在性能方面采取另一种方式。这很大程度上取决于你的功能在做什么。

但同样,重要的可能性非常低。这不会成为您应用中的瓶颈。我根据我认为在上下文中更易维护的情况做出我的决定,并且在我确定调度机制是阻塞点的时候担心性能。 (那从来没有发生在我身上。:-))

答案 1 :(得分:1)

http://jsperf.com/dispatch-table-vs-switch进行了效果比较。它们在性能方面非常相似。我认为使用switch语句或调度表只是基于编码首选项。

一个真实的数据点是Facebook Reactjs库,它倾向于关注可维护性和性能,通常更倾向于在其操作调度程序中使用switch语句。