javascript - Google Closure Compiler 会降低性能吗？

Question

我正在编写 Google Chrome 扩展程序。由于 JavaScript 文件是从磁盘加载的，因此它们的大小几乎无关紧要。

无论如何，我一直在使用 Google Closure Compiler，因为显然它可以进行性能优化并减少代码大小。

但是我在 Closure Compiler 输出的顶部注意到了这一点:

var i = true, m = null, r = false;

这样做的目的显然是减少文件大小(整个脚本中 true/ null/ false 的所有后续使用都可以替换为单个字符)。

但是肯定会有轻微的性能损失吗？阅读文字必须更快 true关键字比按名称查找变量并找到它的值是 true ……？

这种性能下降值得担心吗？ Google Closure Compiler 是否还有其他可能会减慢执行速度的操作？

Answer 1

答案是也许。
让我们看看关闭团队是怎么说的。
From the FAQ :

Does the compiler make any trade-off between my application's execution speed and download code size?

Yes. Any optimizing compiler makes trade-offs. Some size optimizations do introduce small speed overheads. However, the Closure Compiler's developers have been careful not to introduce significant additional runtime. Some of the compiler's optimizations even decrease runtime (see next question).

Does the compiler optimize for speed?

In most cases smaller code is faster code, since download time is usually the most important speed factor in web applications. Optimizations that reduce redundancies speed up the run time of code as well.

我断然挑战他们在这里所做的第一个假设。使用的变量名的大小不会直接影响各种 JavaScript 引擎如何处理代码——事实上，JS 引擎并不关心你是否调用你的变量 supercalifragilisticexpialidocious或 x (但我作为程序员肯定会这样做)。如果您担心交付，下载时间是最重要的部分——我怀疑该工具无法解释的数百万件事情可能会导致脚本运行缓慢。
要真实地理解为什么您的问题是可能的，您首先需要问的是 “是什么让 JavaScript 变快或变慢？”
那么我们当然会遇到这个问题， “我们在谈论什么 JavaScript 引擎？”
我们有:

卡拉坎(歌剧)

查克拉 (IE9+)

SpiderMonkey (Mozilla/FireFox)

SquirrelFish(Apple 的 webkit)

V8 ( Chrome )

Futhark (歌剧)

JScript(IE 9 之前的所有版本)

JavaScriptCore (Konqueror, Safari)

I've skipped out on a few .

这里有人真的认为他们的工作方式都一样吗？尤其是 JScript 和 V8？哎呀不!
再说一次，当谷歌闭包编译代码时，它为哪个引擎构建东西？你觉得幸运吗？
好的，因为我们永远不会涵盖所有这些基础，让我们尝试更一般地看这里，“旧”与"new"代码。
这是来自 one of the best presentations on JS Engines I've ever seen 的此特定部分的快速摘要.
较旧的 JS 引擎

代码被直接解释和编译为字节码

没有优化:一分钱一分货

由于松散类型的语言，代码很难快速运行

新的 JS 引擎

引入实时 (JIT) 编译器以实现快速执行

为真正快速的代码引入类型优化 JIT 编译器(认为接近 C 代码速度)

这里的主要区别在于新引擎引入了 JIT 编译器。
从本质上讲，JIT 将优化您的代码执行，使其运行得更快，但如果发生了它不喜欢的事情，它就会转过身来，使其再次变慢。
你可以通过有两个这样的函数来做这样的事情:

var FunctionForIntegersOnly = function(int1, int2){
    return int1 + int2;
}

var FunctionForStringsOnly = function(str1, str2){
    return str1 + str2;
}

alert(FunctionForIntegersOnly(1, 2) + FunctionForStringsOnly("a", "b"));

通过谷歌关闭运行它实际上将整个代码简化为:

alert("3ab");

而且书中的每个指标都更快。这里真正发生的是它简化了我非常简单的例子，因为它做了一些部分执行。但是，这是您需要小心的地方。
Lets say we have a y-combinator in our code ，编译器把它变成这样的:

(function(a) {
 return function(b) {
    return a(a)(b)
  }
})(function(a) {
  return function(b) {
    if(b > 0) {
      return console.log(b), a(a)(b - 1)
    }
  }
})(5);

不是真的更快，只是缩小了代码。
JIT 通常会看到，在实践中，您的代码只接受该函数的两个字符串输入，并返回一个字符串(或第一个函数的整数)，并将其放入特定于类型的 JIT 中，这使得它非常快。现在，如果谷歌闭包做了一些奇怪的事情，比如将那些具有几乎相同签名的函数转换为一个函数(对于非平凡的代码)，如果编译器做了一些 JIT 不喜欢的事情，你可能会失去 JIT 速度。
那么，我们学到了什么？

您可能拥有 JIT 优化的代码，但编译器会将您的代码重新组织为其他内容

旧浏览器没有 JIT 但仍然可以运行您的代码

Closure 编译的 JS 通过对简单函数执行部分代码来调用更少的函数调用。

所以你会怎么做？

编写小而直的函数，编译器就能更好地处理它们

如果你对 JIT 有很深的理解，手工优化代码，并使用了这些知识，那么闭包编译器可能不值得使用。

如果您希望代码在旧浏览器上运行得更快一点，它是一个很好的工具

权衡通常是值得的，但要小心检查事情，不要一直盲目相信它。

通常，您的代码速度更快。您可能会引入各种 JIT 编译器不喜欢的东西，但如果您的代码使用较小的函数和正确的原型(prototype)面向对象设计，它们将很少见。如果您考虑编译器正在执行的全部功能(更短的下载和更快的执行)，那么奇怪的事情就像 var i = true, m = null, r = false;尽管编译器运行速度较慢，但​​总生命周期更快，这可能是编译器所做的一个值得权衡的折衷。
还值得注意的是，Web 应用程序执行中最常见的瓶颈是文档对象模型，如果您的代码很慢，我建议您在那里投入更多精力。