我遇到了使用各种迷你器和模糊处理器压缩的JavaScript代码的this performance report。令人惊讶的是,除了闭包高级模式之外,在大多数情况下,所有其他微型器输出的代码的性能都比未压缩的代码差。我们该如何解释呢?
向下滚动到page的末尾以查看报告。截图如下:
传奇:
浅蓝色- YUI Compressor
- JS
紫色- JS包装器
发布于 2013-03-17 18:34:04
首先,让我来解释一下:代码实际上并不“执行”任何事情(我的意思是,除了JS Packer之外,没有什么严重的事情)。它本质上是对函数、对象和属性的定义。
JS Packer不生成JavaScript代码,而是生成必须在运行时解压的压缩文本。这就是为什么它慢得多的原因。Google Closure使用高级优化尽可能地替换标识符。所以在解析脚本时已经有了性能上的优势。
也就是说,牺牲性能来换取代码大小是可能的。一个例子是用!0
和!1
替换true
和false
。不过,这取决于JavaScript引擎。它可以在第一次调用之前被引擎优化,在它之后,在几次调用之后,永远不会...谁知道呢;)
新发现
在此期间,我做了一些分析,发现我忘记了一件事:垃圾收集。这种影响足以解释脚本和浏览器之间的一些差异(不同的引擎!)。
结合这一事实,代码并没有做太多的事情,你就有了一些东西。在一次测试中,未压缩的垃圾收集的CPU时间约为3%,而垃圾收集的CPU时间约为9%(!)为了JSMin。这意味着对于几乎相等的代码,结果完全不同。
更新的发现
当你首先运行JSMin时,它比未压缩的要快。我尝试了几次,总是得到相同的结果。这证实了之前的发现。我现在很有信心,我们找到了解决方案。
发布于 2015-12-13 05:07:16
看起来你可能无意中混淆了缩小和混淆。
为了理解这两种技术,我将分别解释它们。
缩小是指缩小源文件的大小,并将其转换为更有效的机器可读性格式的过程。这是通过(a)删除注释和不必要的空格,并可能(b)将变量名替换为通常以一个字符开头的简单增量变量名来实现的。结果代码的功能仍然与原始代码相同,但理论上浏览器的解析和编译速度更快。
混淆是一种对代码进行修改,使其不再能够识别为原始源代码的技术,通常用于阻止对专有代码进行反向工程。其中一些更改可能会有开销,例如,代码可能会在运行时加密,然后再次解密。也就是说,代码混淆器通常也会通过最小化输出来完成工作。
人们可以认为最小化是一种粗糙的模糊形式,但通常这种过程更多地是为了性能和/或带宽目的而执行的。
发布于 2013-03-17 18:22:24
是的,混淆会导致一些性能问题,但缩小的代码比未压缩的代码执行得更差并不是真的。事实上,缩小的代码比未压缩的代码执行得更好。这是因为,精简代码具有更短的变量/函数名,从而使对已分配内存空间的引用调用变得更容易!
https://stackoverflow.com/questions/15458859
复制相似问题