2

http://closure-compiler.appspot.com/home

(function(){

var somevar = 'somevar';

this.each(function(){
var minify_var = {
  method1: somevar + '1', 
  method2: somevar + '2',
  method3: somevar + '3',
  method4: somevar + '4',
  method5: somevar + '5'
};

alert(minify_var);
});

})();

このようなコードは次のように縮小されます。

(function(){this.each(function(){alert({method1:"somevar1",method2:"somevar2",method3:"somevar3",method4:"somevar4",method5:"somevar5"})})})();

長さ (+11 シンボル) で間違いなく大きいものは次のとおりです。

(function(){var a="somevar";this.each(function(){alert({method1:a+"1",method2:a+"2",method3:a+"3",method4:a+"4",method5:a+"5"})})})();

問題は、変数が 2 つあったのに、代わりに 1 つになったことです。

実際、小さなスクリプトでは問題ありませんが、大きなスクリプトでは問題が発生する可能性があります。

最初の変数は、縮小されたコードを少し小さくするために追加されますが、Google はそれを無視します。

また、このような他のサイズ最適化のトリックのほとんどを無視します。

修正できますか?

この質問は、JavaScript パターンではなく、Google Closure に関するものです。

4

2 に答える 2

7

コンパイラは、ファイルがユーザーに提供されるときに gzip されると想定するため、圧縮されていないサイズではなく、圧縮されたファイルのサイズを最適化します。

2 つのバージョンのコードでテストしました。

バージョン A (グローバル変数として扱うaと、後で自動的に連結されなくなります):

(function () {
    a = 'somevar';

    this.each(function () {
        var minify_var = {
            method1: a + '1',
            method2: a + '2',
            method3: a + '3',
            method4: a + '4',
            method5: a + '5'
        };

        alert(minify_var);
    });
})();

縮小されたコードの結果:

(function(){a="somevar";this.a(function(){alert({b:a+"1",c:a+"2",d:a+"3",e:a+"4",f:a+"5"})})})();

サイズ: 97 バイト ( gzip で圧縮された95バイト)。

バージョン B (上記と同じaですが、ローカル変数であるため、コンパイラが最適化を行います):

(function () {
    var a = 'somevar';

    this.each(function () {
        var minify_var = {
            method1: a + '1',
            method2: a + '2',
            method3: a + '3',
            method4: a + '4',
            method5: a + '5'
        };

        alert(minify_var);
    });
})(); 

縮小されたコードの結果:

(function(){this.a(function(){alert({b:"somevar1",c:"somevar2",d:"somevar3",e:"somevar4",f:"somevar5"})})})();

サイズ: 110 バイト ( gzip で圧縮された89バイト)。


したがって、2 番目のバージョンは圧縮されていない方が大きくなりますが、gzip で圧縮すると、変数宣言がなくなり、繰り返されるテキストの長さに関係なく、gzip が繰り返し部分をほぼ同じスペースに圧縮するため、小さくなります。

FAQからのエントリは次のとおりです。

Closure Compiler はすべての文字列をインライン化したため、コード サイズが大きくなりました。なぜそれをしたのですか?

ほとんどの人は、圧縮されていない 2 つの JavaScript ファイルを見てコード サイズを比較します。しかし、JavaScript ファイルは圧縮されていない状態で提供されるべきではないため、これはコード サイズの誤解を招く方法です。gzip 圧縮で提供する必要があります。

Closure Compiler は、gzip 圧縮を使用していることを前提としています。そうでない場合は、そうする必要があります。コードを gzip するようにサーバーを構成することは、実行できる最も効果的で簡単な最適化の 1 つです。gzip アルゴリズムは、最適な方法でバイト シーケンスのエイリアスを作成することによって機能します。文字列を手動でエイリアスすると、ほとんどの場合、圧縮されたコードのサイズが大きくなります。したがって、Closure Compiler は (ほとんど) 可能な場合は常に文字列をインライン化します。これにより、圧縮されたコードが小さくなります。

于 2013-04-06T07:51:58.687 に答える
-1

あらゆる種類のコンパイラ (gcc、g++、jdk など) は、常に次のような問題に直面します: 「速度を求めるか、サイズを求めるか」

この場合、閉鎖はスピードアプローチを採用しています。多くの場所に定数変数があることを認識し、値を直接書き換えました。この問題について閉鎖チームは次のように述べています。

https://developers.google.com/closure/compiler/faq#tradeoffs

コンパイラは、アプリケーションの実行速度とダウンロード コード サイズの間で何らかのトレードオフを行いますか?

はい。最適化コンパイラにはトレードオフがあります。一部のサイズの最適化では、わずかな速度のオーバーヘッドが発生します。ただし、Closure Compiler の開発者は、大幅な追加のランタイムを導入しないように注意しています。コンパイラの最適化の中には、実行時間を短縮するものもあります (次の質問を参照)。

コンパイラは速度を最適化しますか?

ほとんどの場合、ダウンロード時間は通常、Web アプリケーションで最も重要な速度要因であるため、コードが小さいほどコードは高速になります。冗長性を減らす最適化により、コードの実行時間も短縮されます。

于 2013-04-06T08:08:25.370 に答える