为什么Google Closure交换参数？ [英] Why does Google Closure swap arguments?

问题描述

我已经看到Google Closure编译器在if子句中进行了大量的重写。例如：

I've seen the Google Closure compiler do a lot of rewriting in if-clauses. For example:

if (a === 3) {…}

转向

if (3 === a) {…}

如果原语是第一个参数，那么在JavaScript中比较会更快，或者是什么原因是什么？

Are comparisons faster in JavaScript, if the primitive is the first argument, or what is the reason for this?

推荐答案

来自 ReorderConstantExpression.java ：

/**
 * Reorder constant expression hoping for a better compression.
 * ex. x === 0 -> 0 === x
 * After reordering, expressions like 0 === x and 0 === y may have higher
 * compression together than their original counterparts.
 *
 */

如 google closure编译器贡献者，代码注释所指的压缩意味着gzip压缩，而不是实际的缩小压缩。它可以改善gzip压缩的原因是，如果你有 0 === x 和 x === 0 in你的代码，闭包编译器将这两个规范化为 0 === x ，这是重复的文本，因此压缩得更好。

As stated by a google closure compiler contributor, the compression the code comments are referring to means gzip compression, not the actual minification "compression". The reason it can improve gzip compression is that if you have 0 === x and x === 0 in your code, the closure compiler normalizes both of these to 0 === x, which is duplicated text and thus compresses better.

然后还有：

typeof this.value == "object"

typeof this.key == "object"

唯一的字符串是： typeof这个。，值，键和 ==对象

The unique strings are: typeof this., value, key and == "object"

但如果您重新订购：

"object" == typeof this.value

"object" == typeof this.key

唯一的字符串是：object== typeof this。， value 和键。不那么独特的字符串和相当长的重复字符串。

The unique strings are: "object" == typeof this., value and key. Less unique strings and quite a long duplicate one.

这篇关于为什么Google Closure交换参数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！