你如何检测JavaScript中的内存限制？ [英] How do you detect memory limits in JavaScript?

问题描述

浏览器是否可以对可以存储在JavaScript对象中的数据量实施任何限制？如果有，有没有办法检测到这个限制？

Can browsers enforce any sort of limit on the amount of data that can be stored in JavaScript objects? If so, is there any way to detect that limit?

默认情况下，Firefox似乎没有：

It appears that by default, Firefox does not:

var data;
$("document").ready(function() {
  data = [];
  for(var i = 0; i < 100000000000; i++) {
    data.push(Math.random());
  }
});

在我的系统耗尽之前，它会继续消耗越来越多的内存。

That continues to consume more and more memory until my system runs out.

由于我们无法检测可用内存，有没有其他方法可以告诉我们接近这个限制？

Since we can't detect available memory, is there any other way to tell we are getting close to that limit?

更新

我正在开发的应用程序依赖非常快的响应时间来实现（这是核心卖点）。不幸的是，它也有一个非常大的数据集（在较弱的客户端机器上将超过内存）。通过战略性地预先加载数据（猜测将被点击的内容），可以大大提高性能。当猜测不正确时，从服务器加载数据的后退工作正常，但服务器往返不理想。利用每一点内存，我可以使应用程序尽可能高效。

The application I'm developing relies on very fast response times to be usable (it's the core selling point). Unfortunately, it also has a very large data set (more than will fit into memory on weaker client machines). Performance can be greatly improved by preemptively loading data strategically (guessing what will be clicked). The fallback to loading the data from the server works when the guesses are incorrect, but the server round trip isn't ideal. Making use of every bit of memory I can makes the application as performant as possible.

现在，它可以让用户配置他们的性能设置（最大值）数据设置），但用户不想管理它。此外，由于它是一个Web应用程序，我必须处理每台计算机的用户设置（因为强大的桌面比旧的iPhone有更多的内存）。如果它只是对系统上可用的设置使用最佳设置，那就更好了。但猜太高也会导致客户端计算机出现问题。

Right now, it works to allow the user to "configure" their performance settings (max data settings), but users don't want to manage that. Also, since it's a web application, I have to handle users setting that per computer (since a powerful desktop has a lot more memory than an old iPhone). It's better if it just uses optimal settings for what is available on the systems. But guessing too high can cause problems on the client computer too.

推荐答案

虽然在某些浏览器上可能会出现问题但正确的做法应该决定典型客户可以接受的限制，并可选择提供用户界面来定义他们的限制。

While it might be possible on some browsers, the right approach should be to decide what limit is acceptable for the typical customer and optionally provide a UI to define their limit.

大多数重型网络应用程序都可以获得大约10MB的JavaScript堆大小。似乎没有指南。但我想在台式机上消耗超过100MB，在移动设备上消耗20MB并不是很好。对于之后的所有内容，请查看本地存储，例如 FileSystem API （你可以完全让它持久）

Most heavy web apps get away with about 10MB JavaScript heap size. There does not seem to be a guideline. But I would imagine consuming more than 100MB on desktop and 20MB on mobile is not really nice. For everything after that look into local storage, e.g. FileSystem API (and you can totally make it PERSISTENT)

UPDATE

这个答案背后的原因如下。它永远不会让用户只运行一个应用程序。更重要的是依靠浏览器只打开一个标签。最终，消耗所有可用内存永远不是一个好选择。因此，确定上边界是不必要的。

The reasoning behind this answer is the following. It is next to never user runs only one application. More so with counting on the browser having only one tab open. Ultimately, consuming all available memory is never a good option. Hence determining the upper boundary is not necessary.

用户希望分配给Web应用程序的合理内存量是猜测工作。例如。高度交互式数据分析工具在JS中非常有用，可能需要数百万个数据点。一种选择是默认为较低的分辨率（例如，每天而不是每秒测量）或较小的窗口（一天与十几秒）。但随着用户不断探索数据集，将需要越来越多的数据，这可能会削弱代理端的底层操作系统。

Reasonable amount of memory user would like to allocate to the web app is a guess work. E.g. highly interactive data analytics tool is quite possible in JS and might need millions of data points. One option is to default to less resolution (say, daily instead of each second measurements) or smaller window (one day vs. a decade of seconds). But as user keeps exploring the data set, more and more data will be needed, potentially crippling the underlying OS on the agent side.

良好的解决方案是采用一些合理的方法初步假设。让我们打开一些流行的Web应用程序并转到开发工具 - 配置文件 - 堆快照来看看：

Good solution is to go with some reasonable initial assumption. Let's open some popular web applications and go to dev tools - profiles - heap snapshots to take a look:

• FB：18.2 MB


• GMail：33 MB


• Google+：53.4 MB


• YouTube：54 MB


• Bing地图：55 MB

• FB: 18.2 MB
• GMail: 33 MB
• Google+: 53.4 MB
• YouTube: 54 MB
• Bing Maps: 55 MB

注意：这些数字包括堆上的DOM节点和JS对象。

似乎那时，人们开始接受50 MB的RAM用于有用的网站。构建DOM树后，使用测试数据填充数据结构并查看可以保留在RAM中的数量。

It seems to be then, people come to accept 50 MB of RAM for a useful web site. Once you build your DOM Tree, fill your data structures with test data and see how much is ok to keep in RAM.

在Chrome中转换设备模拟时使用类似的测量值，人们可以看到平板电脑和手机上相同网站的消费情况，BTW。

Using similar measurements while turning device emulation in Chrome, one can see the consumption of the same sites on tablets and phones, BTW.

这就是我在台式机上达到100 MB，在手机号码上达到20 MB的方式。似乎也是合理的。当然，对于偶尔的重度用户来说，最好有一个选项可以将最大堆积提高到2 GB。

This is how I arrived at 100 MB on desktop and 20 MB on mobile numbers. Seemed to be reasonable too. Of course, for occasional heavy user it would be nice to have an option to bump max heap up to 2 GB.

现在，如果抽取所有这些数据你会怎么做从服务器每次都太贵了？

Now, what do you do if pumping all this data from the server every time is too costly?

有一件事是使用Application Cache。它确实会产生温和的版本管理难题，但允许您存储大约5 MB的数据。不是存储数据，而是将应用程序代码和资源保留在其中更有用。

One thing is to use Application Cache. It does create mild version management headaches but allows you to store around 5 MB of data. Rather than storing data though, it is more useful to keep app code and resources in it.

除此之外，我们还有三个选择：

Beyond that we have three choices:

• SQLite - 支持有限且似乎被放弃了


• IndexDB - 更好的选择，但支持尚未普及（我可以使用它吗？）


• FileSystem API

• SQLite - support was limited and it seems to be abandoned
• IndexDB - better option, but support is not universal yet (can I use it?)
• FileSystem API

其中，FileSystem最受支持，可以使用相当大的存储空间

Of them, FileSystem is most supported and can use sizeable chunk of storage

这篇关于你如何检测JavaScript中的内存限制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！