首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >为什么缩小或模糊的JavaScript的性能比未压缩的代码差?

为什么缩小或模糊的JavaScript的性能比未压缩的代码差?
EN

Stack Overflow用户
提问于 2013-03-17 16:21:26
回答 3查看 6.2K关注 0票数 19

我遇到了使用各种迷你器和模糊处理器压缩的JavaScript代码的this performance report。令人惊讶的是,除了闭包高级模式之外,在大多数情况下,所有其他微型器输出的代码的性能都比未压缩的代码差。我们该如何解释呢?

向下滚动到page的末尾以查看报告。截图如下:

传奇:

浅蓝色- YUI Compressor

  • Red - Closure (高级模式)

  • 橙色- Closure (基本模式)

- JS

紫色- JS包装器

  • 浅蓝色-YUI-未压缩代码
EN

回答 3

Stack Overflow用户

回答已采纳

发布于 2013-03-17 18:34:04

首先,让我来解释一下:代码实际上并不“执行”任何事情(我的意思是,除了JS Packer之外,没有什么严重的事情)。它本质上是对函数、对象和属性的定义。

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

也就是说,牺牲性能来换取代码大小是可能的。一个例子是用!0!1替换truefalse。不过,这取决于JavaScript引擎。它可以在第一次调用之前被引擎优化,在它之后,在几次调用之后,永远不会...谁知道呢;)

新发现

在此期间,我做了一些分析,发现我忘记了一件事:垃圾收集。这种影响足以解释脚本和浏览器之间的一些差异(不同的引擎!)。

结合这一事实,代码并没有做太多的事情,你就有了一些东西。在一次测试中,未压缩的垃圾收集的CPU时间约为3%,而垃圾收集的CPU时间约为9%(!)为了JSMin。这意味着对于几乎相等的代码,结果完全不同。

更新的发现

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

票数 7
EN

Stack Overflow用户

发布于 2015-12-13 05:07:16

看起来你可能无意中混淆了缩小和混淆。

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

缩小是指缩小源文件的大小,并将其转换为更有效的机器可读性格式的过程。这是通过(a)删除注释和不必要的空格,并可能(b)将变量名替换为通常以一个字符开头的简单增量变量名来实现的。结果代码的功能仍然与原始代码相同,但理论上浏览器的解析和编译速度更快。

混淆是一种对代码进行修改,使其不再能够识别为原始源代码的技术,通常用于阻止对专有代码进行反向工程。其中一些更改可能会有开销,例如,代码可能会在运行时加密,然后再次解密。也就是说,代码混淆器通常也会通过最小化输出来完成工作。

人们可以认为最小化是一种粗糙的模糊形式,但通常这种过程更多地是为了性能和/或带宽目的而执行的。

票数 0
EN

Stack Overflow用户

发布于 2013-03-17 18:22:24

是的,混淆会导致一些性能问题,但缩小的代码比未压缩的代码执行得更差并不是真的。事实上,缩小的代码比未压缩的代码执行得更好。这是因为,精简代码具有更短的变量/函数名,从而使对已分配内存空间的引用调用变得更容易!

票数 -1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/15458859

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档