JavaScriptの配列の最大サイズ

コンテキスト：RSSフィードを読み取り、バックグラウンドでフィードを更新/チェックする小さなサイトを構築しています。表示するデータを格納する配列と、表示されたレコードのIDを格納する配列があります。

質問：物事が遅くなったり遅くなったりする前に、Javascriptで配列が保持できるアイテムの数 私は配列をソートしていませんが、jQueryのinArray関数を使用して比較を行っています。

Webサイトは実行されたままになり、更新されるため、ブラウザが頻繁に再起動/更新されることはほとんどありません。

配列からいくつかのレコードをクリアすることを考える必要がある場合、100アイテムのように、制限の後にいくつかのレコードを削除する最良の方法は何ですか。

「遅くなる」までの最大長は、ターゲットマシンと実際のコードに完全に依存するため、その（これらの）プラットフォームでテストして、何が許容可能かを確認する必要があります。

ただし、ECMA-262 5th Edition仕様による配列の最大長は、ToUint32抽象演算により符号なし32ビット整数によってバインドされるため、可能な最長の配列は2 ³² -1 = 4,294,967,295 = 42.9億要素になる可能性があります。 。

配列をトリムする必要はなく、単に循環バッファー（インデックス％maxlen）としてアドレス指定します。これにより、制限を超えないことが保証されます（循環バッファーを実装すると、最後に到達すると、もう一度最初に戻ります-配列の最後をオーバーランすることはできません）。

例えば：

var container = new Array ();
var maxlen = 100;
var index = 0;

// 'store' 1538 items (only the last 'maxlen' items are kept)
for (var i=0; i<1538; i++) {
   container [index++ % maxlen] = "storing" + i;
}

// get element at index 11 (you want the 11th item in the array)
eleventh = container [(index + 11) % maxlen];

// get element at index 11 (you want the 11th item in the array)
thirtyfifth = container [(index + 35) % maxlen];

// print out all 100 elements that we have left in the array, note
// that it doesn't matter if we address past 100 - circular buffer
// so we'll simply get back to the beginning if we do that.
for (i=0; i<200; i++) {
   document.write (container[(index + i) % maxlen] + "<br>\n");
}

このようなものを試して、長さをテストしてトリミングできます。

http://jsfiddle.net/orolo/wJDXL/

var longArray = [1, 2, 3, 4, 5, 6, 7, 8];

if (longArray.length >= 6) {
  longArray.length = 3;
}

alert(longArray); //1, 2, 3

@maericsが言ったように、ターゲットマシンとブラウザーがパフォーマンスを決定します。

しかし、実際の数値では、2017年のエンタープライズChromebookで操作を実行しています。

console.time();
Array(x).fill(0).filter(x => x < 6).length
console.timeEnd();

• x=5e4 16msかかります、60fpsに十分です
• x=4e6 250ミリ秒かかります。これは目立ちますが、大したことではありません
• x=3e7 1300msかかります、これはかなり悪いです
• x=4e7 11000msかかり、追加の2.5GBのメモリを割り当てます

つまり、JavaScript VMは4,000万要素の崖から落ち、おそらくプロセスをクラッシュさせるため、約3,000万要素がハード上限です。

私は何百万ものデータセットを操作してグラフ化するパフォーマンスフレームワークを構築しましたが、それでも、JavaScript計算のレイテンシは数十ミリ秒のオーダーでした。配列サイズの制限を超えることを心配しているのでない限り、それほど心配する必要はないと思います。

それは非常にブラウザに依存します。100アイテムは多くのように聞こえません-あなたはそれよりもはるかに高くなると思います。何千もの問題はないはずです。問題になる可能性があるのは、合計メモリ消費量です。

私は恥ずかしがらずにかなり大きなデータセットをメモリにプルしましたが、遅くなりましたが、データセットでかなり激しい計算を行うと、15ヶ月以上のデータが必要になりました。データの計算が非常に多く、行数が多い場合を除いて、メモリの問題が発生することはないと思います。異なるモック結果セットを使用したプロファイリングとベンチマークは、パフォーマンスを評価するための最善の方法です。