変数を何度も作成しなければならないのに、なぜ後者の関数は10％高速なのですか？

var toSizeString = (function() {

 var KB = 1024.0,
     MB = 1024 * KB,
     GB = 1024 * MB;

  return function(size) {
    var gbSize = size / GB,
        gbMod  = size % GB,
        mbSize = gbMod / MB,
        mbMod  = gbMod % MB,
        kbSize = mbMod / KB;

    if (Math.floor(gbSize)) {
      return gbSize.toFixed(1) + 'GB';
    } else if (Math.floor(mbSize)) {
      return mbSize.toFixed(1) + 'MB';
    } else if (Math.floor(kbSize)) {
      return kbSize.toFixed(1) + 'KB';
    } else {
      return size + 'B';
    }
  };
})();

そして、より高速な機能：（同じ変数kb / mb / gbを何度も繰り返し計算する必要があることに注意してください）。パフォーマンスはどこで得られますか？

function toSizeString (size) {

 var KB = 1024.0,
     MB = 1024 * KB,
     GB = 1024 * MB;

 var gbSize = size / GB,
     gbMod  = size % GB,
     mbSize = gbMod / MB,
     mbMod  = gbMod % MB,
     kbSize = mbMod / KB;

 if (Math.floor(gbSize)) {
      return gbSize.toFixed(1) + 'GB';
 } else if (Math.floor(mbSize)) {
      return mbSize.toFixed(1) + 'MB';
 } else if (Math.floor(kbSize)) {
      return kbSize.toFixed(1) + 'KB';
 } else {
      return size + 'B';
 }
};

最新のJavaScriptエンジンはすべてジャストインタイムコンパイルを行います。「何度も何度も作成しなければならない」ことについて、推測することはできません。どちらの場合でも、この種の計算は比較的簡単に最適化できます。

一方、定数変数のクローズは、JITコンパイルの対象となる典型的なケースではありません。通常、異なる呼び出しでこれらの変数を変更できるようにする場合は、クロージャーを作成します。また、OOPでのメンバー変数とローカルintへのアクセスの違いのように、これらの変数にアクセスするための追加のポインター逆参照を作成しています。

このような状況が、人々が「時期尚早な最適化」ラインを捨てる理由です。簡単な最適化は、コンパイラーによって既に行われています。

変数は安価です。実行コンテキストとスコープチェーンは高価です。

本質的に「クロージャのため」に要約されるさまざまな答えがあり、それらは本質的に真実ですが、問題はクロージャに特にあるのではなく、異なるスコープの変数を参照する関数があるという事実です。これらがwindowIIFE内のローカル変数ではなく、オブジェクトのグローバル変数である場合、同じ問題が発生します。試してみてください。

したがって、最初の関数では、エンジンが次のステートメントを見ると：

var gbSize = size / GB;

次の手順を実行する必要があります。

1. size現在のスコープで変数を検索します。（それを見つけた。）
2. GB現在のスコープで変数を検索します。（見つかりません。）
3. GB親スコープで変数を検索します。（それを見つけた。）
4. 計算を行い、に割り当てgbSizeます。

ステップ3は、単に変数を割り当てるよりもかなり高価です。また、あなたはこれを行うに5回の両方に二回を含め、GBおよびMB。関数の先頭でこれらvar gb = GBのエイリアスを作成し（例：）、代わりにエイリアスを参照すると、実際にはわずかな高速化が得られますが、一部のJSエンジンはすでにこの最適化を実行している可能性もあります。そしてもちろん、実行を高速化する最も効果的な方法は、単にスコープチェーンをまったく走査しないことです。

JavaScriptは、コンパイラがコンパイル時にこれらの変数アドレスを解決する、コンパイル済みの静的に型付けされた言語とは異なることに注意してください。JSエンジンはそれらを名前で解決する必要があり、これらの検索は実行時に毎回行われます。したがって、可能な場合はそれらを避けたいと思います。

JavaScriptでは、変数の割り当ては非常に安価です。私はその声明をバックアップするものは何もありませんが、実際には最も安価な操作かもしれません。それにもかかわらず、変数の作成を回避しようとすることはほとんど決して良い考えではないと言うのは安全です。その領域で実行しようとするほとんどすべての最適化は、実際にはパフォーマンス面で事態を悪化させることになります。

1つの例にはクロージャーが含まれ、もう1つの例には含まれません。クロージャーの実装は、トリッキーです。変数上でクローズされると、通常の変数のようには機能しません。これは、Cのような低レベル言語ではより明白ですが、JavaScriptを使用してこれを説明します。

クロージャは、関数だけでなく、それが閉じたすべての変数で構成されます。その関数を呼び出したいときは、すべての閉じた変数を提供する必要もあります。これらの閉じた変数を表すオブジェクトを最初の引数として受け取る関数によって、クロージャーをモデル化できます。

function add(vars, y) {
  vars.x += y;
}

function getSum(vars) {
  return vars.x;
}

function makeAdder(x) {
  return { x: x, add: add, getSum: getSum };
}

var adder = makeAdder(40);
adder.add(adder, 2);
console.log(adder.getSum(adder));  //=> 42

closure.apply(closure, ...realArgs)これが必要とする厄介な呼び出し規約に注意してください

JavaScriptの組み込みオブジェクトのサポートにより、明示的なvars引数を省略することが可能になり、this代わりに使用できるようになります。

function add(y) {
  this.x += y;
}

function getSum() {
  return this.x;
}

function makeAdder(x) {
  return { x: x, add: add, getSum: getSum };
}

var adder = makeAdder(40);
adder.add(2);
console.log(adder.getSum());  //=> 42

これらの例は、実際にクロージャーを使用するこのコードと同等です。

function makeAdder(x) {
  return {
    add: function (y) { x += y },
    getSum: function () { return x },
  };
}

var adder = makeAdder(40);
adder.add(2);
console.log(adder.getSum());  //=> 42

この最後の例では、オブジェクトは、返された2つの関数をグループ化するためにのみ使用されます。this結合は無関係です。クロージャーを可能にする詳細-隠されたデータを実際の関数に渡し、クロージャー変数へのすべてのアクセスをその隠されたデータのルックアップに変更する-は、言語によって処理されます。

しかし、クロージャーの呼び出しには、その追加データを渡すオーバーヘッドが含まれ、クロージャーの実行には、その追加データのルックアップのオーバーヘッドが含まれます。クロージャーに依存しないソリューションのパフォーマンスが向上します。特に、クロージャーでできることは、非常に安価な算術演算がいくつかあるためです。これは、解析中に定数に折り畳まれることさえあります。