2012-12-04 1 views
8

Я видел, как компилятор Google Closure много переписывает в if-clauses. Например:Почему Google Closure своп аргументов?

if (a === 3) {…} 

превращается в

if (3 === a) {…} 

ли сравнения быстрее в JavaScript, если примитив является первым аргументом, или что является причиной этого?

+8

Google нравится Yoda :) –

+0

Возможно, вам лучше спросить, что здесь: https://groups.google.com/forum/?fromgroups#!forum/closure-compiler-discuss –

+1

Если есть какое-либо преимущество в производительности , это незначительно, по крайней мере, в Chrome: http://jsperf.com/yoda –

ответ

16

От 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 compiler contributor, компрессия комментарии кода имеют в виду сжатия GZIP средства, а не фактическое минификация «сжатие». Причина, по которой он может улучшить сжатие gzip, заключается в том, что если в вашем коде есть и x === 0, компилятор замыкания нормализует оба из них до 0 === x, который дублируется и, таким образом, сжимается лучше.

Тогда есть:

typeof this.value == "object" 

typeof this.key == "object" 

Уникальные струнами: typeof this., value, key и == "object"

Но если изменить порядок:

"object" == typeof this.value 

"object" == typeof this.key 

Уникальные струнами: "object" == typeof this. , value и key. Меньше уникальных строк и довольно длинный дубликат.

+0

Отлично, приятно. Можно было бы получить более полное описание (в комментарии, а не от вас), но, по крайней мере, там что-то есть. –

+0

+1 для серьезного рытья –

+2

+1. Мне нравится часть исходного кода, в которой говорится, что он расширяет 'AbstractPeepholeOptimization' :) –