最適化に関する最近のスマッシングマガジンの記事を読んだ後、いくつかのテストを実行して、配列の1つの中央から要素を「削除」する最も効果的な方法を確認しました。
配列の中央から値をスプライシングするか、削除するかnullに設定するかについて独自のテストを実行した後、配列から値をスプライシングすると、配列のトラバースが1桁速くなるという予想外の結果に遭遇しました。 。
さらなる調査が私をこれに導きました。
何らかの理由で、配列の最初のレコードを.shift（）すると、トラバースが300倍速くなりました（v8で見られる最大のパフォーマンスですが、試したすべてのブラウザーで有効なようです）。
実際のトラバーサルがボトルネックであるとは思わないので、これを悪用することはないと思いますが、なぜこの動作が発生するのか誰かが知っていますか？
編集： jsPerfの誤った使用は、ここでの根本的な問題でした。以下の私の答えを参照してください。
パフォーマンステストは無数のエラーでいっぱいです。
最も重要なのは、サンプルの長さを1000にすることです。今日のプロセッサでは、1000アイテムの配列のトラバースが即座に実行され、最初に呼び出す配列メソッド（shift、slice、...）よりも多くの時間を測定します。実際の配列トラバーサル。
したがって、
1）はるかに長い配列を使用し、
2）スライス/シフト/ ...を実行する必要があります。これは、測定したいものではないため、ループの前に行います。
次に、魔法がないこと、および配列トラバーサルがすべての配列で同じ時間かかることがわかります。
通常/sliced（0,0）およびshift（）の場合、 http：//jsperf.com/spliced-vs-non-spliced/4から始めました。性能の違いは、測定誤差より劣ります。
そこで、コア配列関数をforループ自体と比較して、各関数からforループを削除してみました。
http://jsperf.com/spliced-vs-non-spliced/3
ベンチマークは、各関数の内部動作におけるこれらの単純な違いにより、桁違いにスケーリングされています。最小限の部分に単純化することで、実際の違いを分離することができます。これに基づいて、forループが実際に高速または低速でトラバースしているとは思えません。テストの他の関数のために、そのように表示されます。
誤解にもかかわらず、配列関数がどのように機能し、JavaScript開発者がそれらをどのように適用すべきかを明らかにすることは依然として非常に役立ちます。
さて、これは実際にはjsPerfがどのように機能するかについての私の側の誤解であることがわかりました。
スクリプトのセットアップセクションは、スクリプトを試行するたびに実行するのではなく、ループの各セットの最初に実行されるものです。
ここに示されているように、実際の数値は予想どおりになります。