评论会影响绩效吗?

时间:2012-04-19 16:54:25

标签: javascript performance loops comments function-prototypes

我是否正确地说JavaScript代码没有编译,甚至不是JIT?如果是这样,这是否意味着评论会对绩效产生影响,我应该非常小心地将评论放在哪里?比如在可能的情况下在函数定义的上方和外部放置函数注释,并且如果我想最大化性能,肯定避免在循环中放置注释?我知道在大多数情况下(至少在非循环情况下),性能的变化可以忽略不计,但我认为这将是一件值得了解和了解的事情,尤其是对于前端/ js开发人员。另外,我最近对js评估提出了一个相关问题。

5 个答案:

答案 0 :(得分:23)

  

我是否正确地说JavaScript代码未编译,甚至不是JIT?

没有。虽然JavaScript传统上是一种“解释”语言(尽管不一定如此),但大多数JavaScript引擎在必要时即时编译它。 V8(Chrome和NodeJS中的引擎)用于立即快速编译,然后返回并积极优化任何使用过的代码(旧的FullCodegen + TurboFan堆栈);前一段时间做了大量的实际测量,they switched最初解析为byteocde和解释,然后编译代码是否被重用(新的Ignition + TurboFan堆栈),通过以下方式获得显着的内存节省不编译运行一次设置代码。即使是攻击性较低的引擎,也几乎肯定会将文本解析为某种形式的字节码,尽早丢弃注释。

请记住,“解释”与“编译”通常更像是一种环境而非语言的东西;有C语言解释器,还有JavaScript编译器。语言往往与环境紧密相关(就像JavaScript与Web浏览器环境的关系一样,即使它总是被广泛使用,甚至早在1995年),但即便如此(如我们所见),可能有变化。

  

如果是这样,这是否意味着评论会对绩效产生影响......

在初始解析阶段非常非常非常最小的一个。但评论很容易扫描过去,无需担心。

但是,如果您真的担心它,可以使用jsminClosure Compiler等工具缩小脚本(即使只进行简单的优化)。前者只会删除评论和不必要的空白,这样的东西(仍然非常有效);后者确实实际上理解代码并做了一些内联等等。因此,您可以自由发表评论,然后使用这些工具确保使用缩小工具绕过首次加载脚本时这些评论可能产生的微小影响。

当然,关于JavaScript性能的事情是,很难可靠地预测跨引擎,因为引擎变化很大。所以实验很有趣:

  • Here's一个实验(理论上)每次重复/重新创建函数
  • Here's one只解析/创建一次函数并重复使用

结果?我的看法是测试的测量误差没有明显的区别。

答案 1 :(得分:7)

评论的最大影响是膨胀文件大小,从而减慢脚本的下载速度。因此,为什么所有专业网站都使用最小化器来生成高效版本,将js缩小到最小值。

答案 2 :(得分:3)

可能会产生一些影响。但是非常简约的效果(即使IE6正确处理评论!待确认...... )。

然而,大多数人使用缩小评论的缩小器。所以没关系。

此外:

  

V8通过在执行本机代码之前将JavaScript编译为本机代码来提高性能。

Source

答案 3 :(得分:0)

can prevent functions from being inlined,它会影响性能,尽管这种情况并非应该真正发生。

答案 4 :(得分:0)

在某些也许是孤立的情况下,注释肯定以某种方式使代码执行陷入困境。我写了一个冗长的用户脚本,在Mac上使用TamperMonkey的最新Firefox中使用,并且几天后,越来越烦人的故障排除工作结束了,当时我从脚本中删除了冗长的注释,突然脚本执行完全停止在Facebook上挂起。多次来回比较在一个新用户帐户上运行了相同的确切脚本,唯一的区别是注释,事实证明是这种情况。