ホームページ > 記事 > ウェブフロントエンド > データ構造の観点から見ると、各 in は in_javascript スキルよりもはるかに高速です
Firefox の JS エンジンは、次のコードのような for each 構文をサポートしていると聞きました:
FireFox のみがこれをサポートしているため、ほとんどすべての JS コードはこの機能を使用しません。
ただし、ActionScript は本質的に、配列、ベクトル、辞書に関係なく、列挙可能なオブジェクトである限り、for in および for each in をサポートします。
以前は、「each」という単語を入力するのが面倒だったので、いつも使い慣れた for in を使って横断していました。
しかし、今日よく考えてデータ構造の観点から分析してみると、JSであってもASであっても、for inとfor each inでは効率に本質的な違いがあるように感じます。
理由は簡単です。配列は本当の意味での配列ではないからです。
配列の本当の意味は何ですか?もちろん、これは従来の言語で type[] で定義されたデータ型であり、すべての要素が継続的に保存されます。
「配列」は配列という意味もありますが、JS に詳しい人は、これが実際には非線形の擬似配列であり、添え字は任意の数であることを知っています。 arr[1000000] と記述すると、実際には 100 万要素を収容するためのスペースが適用されませんが、1000000 が対応するハッシュ値に変換され、小さな記憶スペースに相当するため、メモリが大幅に節約されます。
たとえば、次のような配列があります:
for...in を使用して配列を走査するのは非常に面倒なプロセスです:
トラバーサル中に arr[k] にアクセスするたびに、ハッシュ テーブルの容量に基づいてモジュロ計算を実行する必要があります。競合がある場合は、最終的な値の結果を見つける必要があります。
for each...in 構文がサポートされている場合、その内部データ構造により、次のようにより高速になることが決定されます:
配列では、各値はノードとして直接使用され、リンクされたリストを通じて維持されます。値が追加または削除されるたびに、そのリンク関係が更新されます。
for each...in をトラバースする場合、ハッシュ計算を行わずに、最初のノードから逆方向に反復するだけで済みます。
もちろん、AS3 の Vector などの線形配列の場合、両者に大きな違いはありません。同様に、HTML5 のバイナリ配列 ArrayBuffer にも同じことが当てはまります。ただし、理論的な観点から見ると、たとえ arr が連続線形配列であっても、for each in のほうが高速です:
for...in を走査するとき、arr[k] がアクセスされるたびに、添字が範囲外チェックを実行する必要があり、各 in は内部リンク リストに基づいて反復変数を最下層から直接フィードバックするため、範囲外チェックのプロセスが省略されます。