データ構造の観点から見ると、各 in は in_javascript スキルよりもはるかに高速です

Firefox の JS エンジンは、次のコードのような for each 構文をサポートしていると聞きました:

コードをコピー コードは次のとおりです。

var arr = [10,20,30 ,40, 50];
for each(var k in arr)
console.log(k);

arr 配列の内容を直接走査できます。

FireFox のみがこれをサポートしているため、ほとんどすべての JS コードはこの機能を使用しません。

ただし、ActionScript は本質的に、配列、ベクトル、辞書に関係なく、列挙可能なオブジェクトである限り、for in および for each in をサポートします。

以前は、「each」という単語を入力するのが面倒だったので、いつも使い慣れた for in を使って横断していました。

しかし、今日よく考えてデータ構造の観点から分析してみると、JSであってもASであっても、for inとfor each inでは効率に本質的な違いがあるように感じます。

理由は簡単です。配列は本当の意味での配列ではないからです。

配列の本当の意味は何ですか?もちろん、これは従来の言語で type[] で定義されたデータ型であり、すべての要素が継続的に保存されます。

「配列」は配列という意味もありますが、JS に詳しい人は、これが実際には非線形の擬似配列であり、添え字は任意の数であることを知っています。 arr[1000000] と記述すると、実際には 100 万要素を収容するためのスペースが適用されませんが、1000000 が対応するハッシュ値に変換され、小さな記憶スペースに相当するため、メモリが大幅に節約されます。
たとえば、次のような配列があります:

コードをコピー コードは次のとおりです:

var arr = [];
arr[10] = 1000;
arr[20] = 2000;
arr[30] = 5000;
arr[40] = 8000;
arr[200] = 9000;

for...in を使用して配列を走査するのは非常に面倒なプロセスです:

トラバーサル中に arr[k] にアクセスするたびに、ハッシュ テーブルの容量に基づいてモジュロ計算を実行する必要があります。競合がある場合は、最終的な値の結果を見つける必要があります。

for each...in 構文がサポートされている場合、その内部データ構造により、次のようにより高速になることが決定されます:

配列では、各値はノードとして直接使用され、リンクされたリストを通じて維持されます。値が追加または削除されるたびに、そのリンク関係が更新されます。
for each...in をトラバースする場合、ハッシュ計算を行わずに、最初のノードから逆方向に反復するだけで済みます。

もちろん、AS3 の Vector などの線形配列の場合、両者に大きな違いはありません。同様に、HTML5 のバイナリ配列 ArrayBuffer にも同じことが当てはまります。ただし、理論的な観点から見ると、たとえ arr が連続線形配列であっても、for each in のほうが高速です:

for...in を走査するとき、arr[k] がアクセスされるたびに、添字が範囲外チェックを実行する必要があり、各 in は内部リンク リストに基づいて反復変数を最下層から直接フィードバックするため、範囲外チェックのプロセスが省略されます。