Google Closure Compiler 是否会降低性能？

Question

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

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

但我在闭包编译器的输出顶部注意到了这一点：

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

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

但这肯定会对性能造成轻微影响吗？仅仅读取文字 true 关键字肯定比通过名称查找变量并发现其值为 true 更快...？

这种性能打击值得担心吗？ Google Closure Compiler 还有其他什么可能实际上会减慢执行速度吗？

Answer 1

答案是也许。

让我们看看关闭团队对此有何评论。

来自常见问题解答：

编译器是否会在应用程序的执行速度和下载代码大小之间进行权衡？

是的。任何优化编译器都会做出权衡。 某些大小优化确实会带来较小的速度开销。但是，闭包编译器的开发人员一直很小心，不要引入大量额外的运行时。 某些编译器的优化甚至会减少运行时间（请参阅下一个问题）。

编译器是否优化了速度？

在大多数情况下，较小的代码是更快的代码，因为下载时间通常是 Web 应用程序中最重要的速度因素。减少冗余的优化也可以加快代码的运行时间。

我断然质疑他们在这里做出的第一个假设。使用的变量名称的大小不会直接影响各种 JavaScript 引擎处理代码的方式 - 事实上，JS 引擎并不关心您是否将变量称为 supercalifragilisticexpialidocious 或 x（但我作为一名程序员肯定会这样做）。如果您担心交付，下载时间是最重要的部分 - 运行缓慢的脚本可能是由数百万个我怀疑该工具根本无法解释的事情引起的。

要真正理解为什么你的问题是可能的，你需要问的第一件事是“是什么让 JavaScript 变得更快或更慢？”

然后当然我们会遇到这个问题，“我们是什么 JavaScript 引擎 SpiderMonkey

我们有：

• Carakan (Opera)
• Chakra (IE9+)
• (Mozilla/FireFox)
• SquirrelFish (Apple 的 webkit)
• V8 (Chrome)
• Futhark (Opera)
• JScript (所有版本9 之前的 IE）
• JavaScriptCore（Konqueror、Safari）
• 我跳过了一些。

这里有人真的认为它们的工作原理都是一样的吗？尤其是 JScript 和 V8？哎呀不！

那么，当谷歌闭包编译代码时，它是为哪个引擎构建东西的？你觉得幸运吗？

好吧，因为我们永远不会涵盖所有这些基础，所以让我们尝试更广泛地查看“旧”代码与“新”代码。

以下是来自 关于 JS 引擎的最佳演示之一的此特定部分的快速摘要见过。

较旧的 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"));

通过 google 闭包运行它实际上将整个代码简化为：

alert("3ab");

并且根据书中的每个指标，速度更快。这里真正发生的是它简化了我非常简单的示例，因为它做了一些部分执行。然而，这是您需要小心的地方。

假设我们的代码中有一个 y 组合器，编译器将其转换为如下所示

(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 中，这使得它非常快。现在，如果 google 闭包做了一些奇怪的事情，比如将那些具有几乎相同签名的函数转换为一个函数（对于不平凡的代码），如果编译器做了 JIT 不喜欢的事情，您可能会失去 JIT 速度。

那么，我们学到了什么？

• 你可能有 JIT 优化的代码，但编译器将你的代码重新组织成其他东西
• 旧浏览器没有 JIT，但仍然运行你的代码
• 闭包编译的 JS 通过对简单函数的代码进行部分执行来调用更少的函数调用。

那么你做什么呢？

• 编写小而中肯的函数，编译器将能够更好地处理它们。
• 如果您对 JIT 有非常深入的了解，手工优化代码，并使用了这些知识，那么闭包编译器可能不值得使用。
• 如果您希望代码在较旧的浏览器上运行得更快一点，那么它是一个出色的工具。
• 权衡通常是值得的，但要小心检查，不要一直盲目信任它。

一般来说，您的代码速度更快。您可能会引入各种 JIT 编译器不喜欢的东西，但如果您的代码使用较小的函数和正确的原型面向对象设计，那么它们就会很少见。如果您考虑编译器正在执行的全部操作（更短的下载和更快的执行），那么诸如 var i = true, m = null, r = false; 之类的奇怪事情可能是值得的尽管编译器运行速度较慢，但​​总生命周期却更快。

还值得注意的是，Web 应用程序执行中最常见的瓶颈是文档对象模型，如果您的代码很慢，我建议您在这方面投入更多精力。

Answer 2

看起来，在现代浏览器中，使用文字 true 或 null 与变量相比，在几乎所有情况下都绝对没有区别（例如零；它们是完全相同的）。在极少数情况下，变量实际上更快。

因此，节省这些额外的字节是值得的，而且不需要任何成本。

true 与变量 (http://jsperf.com/true-vs-variable ):

null 与变量 (http://jsperf.com/null-vs-variable):

Answer 3

我认为性能会有非常轻微的损失，但在较新的现代浏览器中不太可能产生太大影响。

请注意，闭包编译器的标准别名变量都是全局变量。这意味着，在旧版浏览器中，JavaScript 引擎需要线性时间来导航功能范围（例如 IE < 9），嵌套函数调用越深，找到包含“true”或“true”的变量所需的时间就越长。几乎所有现代 JavaScript 引擎都会优化全局变量访问，因此在许多情况下这种惩罚不应再存在。

此外，除了赋值或参数之外，实际上不应该在很多地方直接在编译代码中看到“true”或“false”或“null”。例如： if (someFlag == true) ... 大部分只是写成 if (someFlag) ... ，由编译器编译为 a & ;& ...。您大多只在赋值 (someFlag = true;) 和参数 (someFunc(true);) 中看到它们，这种情况实际上并不经常发生。

结论是：尽管许多人怀疑闭包编译器的标准别名（包括我）的有用性，但您不应该期望任何实质性的性能影响。不过，您也不应该指望 gzipped 大小会带来任何物质上的好处。