型付き配列は、パフォーマンス上の理由から、WebGL標準化委員会によって設計されました。通常、Javascript配列は汎用であり、オブジェクトや他の配列などを保持できます。要素は、Cの場合のように、必ずしもメモリ内でシーケンシャルである必要はありません。WebGLでは、基になるC APIが期待する方法であるため、バッファがメモリ内でシーケンシャルである必要があります。彼ら。型付き配列を使用しない場合、通常の配列をWebGL関数に渡すには、多くの作業が必要です。各要素を検査し、型をチェックし、それが正しい場合（floatなど）、別のシーケンシャルにコピーする必要があります。 Cのようなバッファ、次にそのシーケンシャルバッファをCAPIに渡します。痛い-たくさんの仕事！パフォーマンスに敏感なWebGLアプリケーションの場合、これによりフレームレートが大幅に低下する可能性があります。
一方、質問で示唆しているように、型付き配列は、舞台裏のストレージにすでにあるシーケンシャルCのようなバッファーを使用します。型付き配列に書き込む場合、実際には、舞台裏でCのような配列に割り当てています。WebGLの目的では、これは、対応するCAPIがバッファーを直接使用できることを意味します。
メモリアドレスの計算だけでは不十分であることに注意してください。範囲外のアクセスを防ぐために、ブラウザも配列を境界チェックする必要があります。これはあらゆる種類のJavascript配列で発生する必要がありますが、多くの場合、巧妙なJavascriptエンジンは、インデックス値がすでに範囲内にあることを証明できる場合（0から配列の長さへのループなど）にチェックを省略できます。また、配列インデックスが実際には数値であり、文字列などではないことを確認する必要があります。しかし、本質的には、Cのようなアドレス指定を使用して説明するのと同じです。
しかし...それだけではありません！場合によっては、巧妙なJavascriptエンジンで、通常のJavascript配列のタイプを推測することもできます。V8のようなエンジンでは、通常のJavascript配列を作成し、それにfloatのみを格納すると、V8はそれがfloatの配列であると楽観的に判断し、そのために生成するコードを最適化する場合があります。その場合、パフォーマンスは型付き配列と同等になります。したがって、最大のパフォーマンスを達成するために、型付き配列は実際には必要ありません。配列を予測どおりに使用するだけで（すべての要素が同じ型で）、一部のエンジンもそのために最適化できます。
では、なぜ型付き配列がまだ存在する必要があるのでしょうか。
- 配列のタイプを推測するような最適化は本当に複雑です。V8が、通常の配列にfloatのみが含まれていると推測した場合、オブジェクトを要素に格納します。最適化を解除して、配列を再びジェネリックにするコードを再生成する必要があります。これらすべてが透過的に機能することは、かなりの成果です。型付き配列ははるかに単純です。1つの型であることが保証されており、オブジェクトなどの他のものを格納することはできません。
- 最適化が行われることが保証されることはありません。通常の配列にはfloatのみを格納できますが、エンジンはさまざまな理由でそれを最適化しないことを決定する場合があります。
- それらがはるかに単純であるという事実は、他のそれほど洗練されていないjavascriptエンジンがそれらを簡単に実装できることを意味します。高度な最適化解除のサポートはすべて必要ありません。
- 非常に高度なエンジンを使用しても、最適化を使用できることを証明することは非常に困難であり、不可能な場合もあります。型付き配列は、エンジンがその周りで最適化できる必要がある証明のレベルを大幅に簡素化します。型付き配列から返される値は確かに特定の型であり、エンジンはその型の結果を最適化できます。通常の配列から返される値は理論的には任意の型である可能性があり、エンジンは常に同じ型の結果になることを証明できない可能性があるため、効率の低いコードが生成されます。したがって、型付き配列の周りのコードはより簡単に最適化されます。
- 型付き配列は、間違いを犯す機会を取り除きます。誤ってオブジェクトを保存して、突然パフォーマンスが大幅に低下することはありません。
したがって、要するに、通常の配列は、理論的には型付き配列と同じくらい高速である可能性があります。ただし、型付き配列を使用すると、ピークパフォーマンスに到達するのがはるかに簡単になります。