Javascript 中数组的最大大小
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/6154989/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Maximum size of an Array in Javascript
提问by addedlovely
Context: I'm building a little site that reads an rss feed, and updates/checks the feed in the background. I have one array to store data to display, and another which stores ID's of records that have been shown.
上下文：我正在构建一个读取 rss 提要并在后台更新/检查提要的小站点。我有一个数组来存储要显示的数据，另一个数组存储已显示的记录的 ID。
Question: How many items can an array hold in Javascript before things start getting slow, or sluggish. I'm not sorting the array, but am using jQuery's inArray function to do a comparison.
问题：在事情开始变慢或缓慢之前，一个数组可以在 Javascript 中保存多少项。我没有对数组进行排序，而是使用 jQuery 的 inArray 函数进行比较。
The website will be left running, and updating and its unlikely that the browser will be restarted / refreshed that often.
该网站将保持运行和更新，并且浏览器不太可能经常重新启动/刷新。
If I should think about clearing some records from the array, what is the best way to remove some records after a limit, like 100 items.
如果我应该考虑从数组中清除一些记录，那么在限制之后删除一些记录的最佳方法是什么，例如 100 个项目。
回答by maerics
The maximum length until "it gets sluggish" is totally dependent on your target machine and your actual code, so you'll need to test on that (those) platform(s) to see what is acceptable.
“它变得缓慢”之前的最大长度完全取决于您的目标机器和您的实际代码，因此您需要在该（那些）平台上进行测试以查看可接受的内容。
However, the maximum length of an array according to the ECMA-262 5th Edition specification is bound by an unsigned 32-bit integer due to the ToUint32abstract operation, so the longest possible array could have 232-1 = 4,294,967,295 = 4.29 billion elements.
但是，根据 ECMA-262 第 5 版规范，由于ToUint32抽象操作，数组的最大长度受无符号 32 位整数的约束，因此可能的最长数组可能有 2 32-1 = 4,294,967,295 = 42.9 亿个元素.
回答by Lelanthran
No need to trim the array, simply address it as a circular buffer (index % maxlen). This will ensure it never goes over the limit (implementing a circular buffer means that once you get to the end you wrap around to the beginning again - not possible to overrun the end of the array).
无需修剪数组，只需将其作为循环缓冲区寻址（索引 % maxlen）。这将确保它永远不会超过限制（实现循环缓冲区意味着一旦到达末尾，您将再次返回到开头 - 不可能超出数组的末尾）。
For example:
例如：
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");
}
回答by orolo
You could try something like this to test and trim the length:
你可以尝试这样的事情来测试和修剪长度：
http://jsfiddle.net/orolo/wJDXL/
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回答by Carl Walsh
Like @maerics said, your target machine and browser will determine performance.
就像@maerics 所说的，您的目标机器和浏览器将决定性能。
But for some real world numbers, on my 2017 enterprise Chromebook, running the operation:
但是对于一些真实世界的数字，在我 2017 年的企业 Chromebook 上，运行以下操作：
console.time();
Array(x).fill(0).filter(x => x < 6).length
console.timeEnd();
x=5e4takes 16ms, good enough for 60fpsx=4e6takes 250ms, which is noticeable but not a big dealx=3e7takes 1300ms, which is pretty badx=4e7takes 11000ms and allocates an extra 2.5GB of memory
x=5e4需要 16ms，足够 60fpsx=4e6需要 250 毫秒，这很明显，但没什么大不了的x=3e7需要 1300 毫秒，这很糟糕x=4e7需要 11000ms 并分配额外的 2.5GB 内存
So around 30 million elements is a hard upper limit, because the javascript VM falls off a cliff at 40 million elements and will probably crash the process.
所以大约 3000 万个元素是一个硬上限，因为 javascript VM 在 4000 万个元素时掉下悬崖并且可能会导致进程崩溃。
回答by Razor Storm
I have built a performance framework that manipulates and graphs millions of datasets, and even then, the javascript calculation latency was on order of tens of milliseconds. Unless you're worried about going over the array size limit, I don't think you have much to worry about.
我已经构建了一个性能框架来操作和绘制数百万个数据集，即使这样，javascript 计算延迟也只有几十毫秒。除非您担心超过数组大小限制，否则我认为您不必担心。
回答by rjmunro
It will be very browser dependant. 100 items doesn't sound like a large number - I expect you could go a lot higher than that. Thousands shouldn't be a problem. What may be a problem is the total memory consumption.
它将非常依赖浏览器。100 件物品听起来不是一个很大的数字——我希望你能得到比这高得多的数字。几千应该不是问题。可能有问题的是总内存消耗。
回答by stefgosselin
I have shamelessly pulled some pretty big datasets in memory, and altough it did get sluggish it took maybe 15 Mo of data upwards with pretty intense calculations on the dataset. I doubt you will run into problems with memory unless you have intense calculations on the data and many many rows. Profiling and benchmarking with different mock resultsets will be your best bet to evaluate performance.
我无耻地在内存中提取了一些相当大的数据集，虽然它确实变得缓慢，但它可能需要 15 个月的数据向上，并对数据集进行非常密集的计算。我怀疑除非您对数据和许多行进行大量计算，否则您会遇到内存问题。使用不同的模拟结果集进行分析和基准测试将是评估性能的最佳选择。
