【问题标题】:How can I optimize a switch statement on the numbers 1, 2, 3, 4如何优化数字 1、2、3、4 的 switch 语句
【发布时间】:2016-11-05 03:36:48
【问题描述】:

所以,我有一段类似的 Javascript 代码

switch (n)
{
case 1:
// ...
case 2:
// ...
case 3:
// ...
case 4:
// ...
default: 
// never happens
}

但是,我意识到存在问题,因为在检查 n13 时会有冗余,因为如果 1 的第一位是关闭的,那么 3 甚至不需要被检查;同样,如果2 的第一位打开,则4 甚至不需要检查。如何优化此过程?我需要快速的代码,因为这个逻辑是运行速度非常快的游戏的一部分。

【问题讨论】:

  • cpus 在比较数字时不比较单个位。他们一次比较所有位。你在优化完全错误的东西。
  • 一共多少例?
  • 好吧,Knuth 博士,运行时解释 switch 语句的效率比你想象的要高。
  • 如果现代引擎没有自动优化它以直接跳转到正确的情况,我会有点惊讶,只要它可以确定 n 始终是一个数字。
  • @Pointy:是的,这就是为什么如果这还没有优化我会感到惊讶的原因。 “跳台”是正确的术语吗?

标签: javascript algorithm optimization


【解决方案1】:

使用数组

myCommand[n]

以命令对象作为元素。

【讨论】:

  • 您已经证实这会更快?并不是说不是,但由于 JS 数组是对象,它们可以在某些情况下进行高度优化,而在其他情况下则不行。然后函数调用也需要开销(尽管 OP 可能以类似的方式调用函数,但无法判断).
【解决方案2】:

JavaScript 被解释,因此您尝试进行的任何优化都将比 JavaScript 解释器的优化慢,后者将被编译并运行得更快。

别担心。

【讨论】:

  • 这通常是错误的。请解释你的答案。
  • 我不理解 "JavaScript 被解释,所以..." 部分。它如何被解释帮助?
  • @cookiemonster 因为解释型语言通常比编译型语言运行得慢
  • 哦,我明白你在说什么,但我不知道我是否一定同意这么宽泛的说法。毕竟,switch 语句也被解释了。我认为 OP 是在询问是否有任何结构或方法可以比 switch 有更好的优化。
  • 我不认为这个答案是最佳措辞,但这确实是一个很好的观点 - JavaScript 源代码中的微优化可能今天有所帮助,但明天一些高手会工作在 V8 代码上可能有一个好主意,它使你的 hack 变得无关紧要,或者实际上比简单的代码慢。乔阿姆斯特朗,Erlang 人,总是告诉人们“写出你能写的最漂亮的代码”。无论如何,慢代码几乎总是一个算法问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-11-07
  • 2021-07-04
相关资源
最近更新 更多