javascript - 为什么缩小或混淆的 JavaScript 比未压缩的代码执行得更差？

Question

我遇到了这份使用各种压缩器和混淆器压缩的 JavaScript 代码的性能报告。令人惊讶的是，除了 Closure 高级模式之外，在大多数情况下，所有其他压缩器输出的代码都比未压缩的代码执行得更差。我们如何解释呢？

向下滚动到页面末尾以查看报告。以下是截图：

传奇：

• 蓝色 - YUI 压缩机
• 红色 - 关闭（高级模式）
• 橙色 - 关闭（基本模式）
• 绿色 - JS Min
• 紫色 - JS Packer
• 浅蓝色 - UglifyJS
• 粉红色 - 未压缩代码

Answer 1

首先让我扮演魔鬼的拥护者：代码实际上并没有“执行”任何事情（我的意思是没什么严重的，除了 JS Packer）。它本质上是函数、对象和属性的定义。

JS Packer 不生成 JavaScript 代码，而是生成必须在运行时解压缩的压缩文本。这就是为什么它要慢得多。使用高级优化的 Google Closure 会尽可能替换标识符。所以在解析脚本时已经有了性能优势。

也就是说，有可能牺牲代码大小的性能。一个例子是将trueandfalse替换为!0and !1。不过，这取决于 JavaScript 引擎。它可以在第一次调用之前、之后、之后、在一些调用之后由引擎优化，从不......谁知道;）

新发现

与此同时，我做了一些分析，并意识到我忘记了一件事：垃圾收集。这种影响足以解释脚本和浏览器之间的一些差异（不同的引擎！）。

将其与代码并没有做太多事情的事实相结合，并且您有一些东西。在一项测试中，未压缩的垃圾收集 CPU 时间约为 3%，JSMin 的垃圾收集时间约为 9%（！）。这意味着几乎相同的代码的结果完全不同。

甚至更新的发现

当您首先运行 JSMin 时，它比未压缩的要快。我尝试了几次，总是得到相同的结果。这证实了之前的发现。我现在非常有信心，我们找到了解决方案。

Answer 2

看来您可能无意中将缩小与混淆混淆了。

为了理解这两种技术，我将分别解释它们。

缩小是减少源文件大小的过程，并将其制成旨在提高机器可读性的格式。这是通过 (a) 删除注释和不必要的空格，并可能 (b) 用简单的增量变量名替换变量名来完成的，这些变量名通常以一个字符开头。生成的代码的功能仍然与原始代码相同，但理论上浏览器解析和编译速度更快。

混淆是一种修改代码以使其不再被识别为原始源代码的技术，通常用于阻止专有代码的逆向工程。某些更改可能会对它们产生开销，例如代码可能会在运行时被加密然后再次解密。也就是说，代码混淆器通常也会通过缩小输出来完成工作。

人们可以认为缩小是一种粗略的混淆形式，但通常执行此类过程更多是出于性能和/或带宽目的。

Answer 3

是的，混淆可能会导致一些性能问题，但缩小代码的性能不如未压缩的代码是不正确的。事实上，压缩后的代码比未压缩的代码执行得更好。这是因为，minfied 代码具有更短的变量/函数名称，因此对分配的内存空间的引用调用更容易！