Подтвердить что ты не робот

Как определить пределы памяти в JavaScript?

Могут ли браузеры применять какой-либо лимит на количество данных, которые могут храниться в объектах JavaScript? Если да, есть ли способ определить этот предел?

Похоже, что по умолчанию Firefox не делает:

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

Это продолжает потреблять все больше и больше памяти, пока моя система не закончится.

Поскольку мы не можем обнаружить доступную память, есть ли другой способ сказать, что мы приближаемся к этому пределу?

Обновление

Приложение, которое я разрабатываю, полагается на очень быстрое время отклика для использования (это основная точка продажи). К сожалению, он также имеет очень большой набор данных (больше, чем вписывается в память на более слабых клиентских машинах). Производительность может быть значительно улучшена за счет предварительной загрузки данных стратегически (угадайте, что будет нажата). Возврат к загрузке данных с сервера работает, когда догадки неверны, но поездка в оба конца не идеальна. Используя каждый бит памяти, я могу сделать приложение максимально возможным.

В настоящее время он позволяет пользователю "настроить" свои параметры производительности (максимальные настройки данных), но пользователи не хотят этого делать. Кроме того, поскольку это веб-приложение, я должен обрабатывать пользователей, настраивающих их для каждого компьютера (поскольку у мощного рабочего стола гораздо больше памяти, чем у старого iPhone). Это лучше, если он просто использует оптимальные настройки для того, что доступно в системах. Но слишком высокая догадка может вызвать проблемы и на клиентском компьютере.

4b9b3361

Ответ 1

Хотя это возможно в некоторых браузерах, правильный подход должен состоять в том, чтобы решить, какой предел приемлем для типичного клиента и, возможно, предоставить пользовательский интерфейс для определения своего предела.

Большинство тяжелых веб-приложений уходят с размером кучи размером в 10 МБ. Кажется, что нет руководства. Но я бы предположил, что потреблять более 100 МБ на рабочем столе и 20 МБ на мобильном телефоне не очень приятно. Для всего, что происходит после этого, смотрите на локальное хранилище, например. API файловой системы (и вы можете полностью сделать это PERSISTENT)

ОБНОВЛЕНИЕ

Обоснованием этого ответа является следующее. Рядом с ним никогда не запускается только одно приложение. Тем более с учетом того, что браузер имеет только одну вкладку. В конечном счете, потребление всей доступной памяти никогда не является хорошим вариантом. Следовательно, определение верхней границы не требуется.

Разумный объем памяти, который пользователь хотел бы выделить для веб-приложения, - это работа с предположениями. Например. высокоинтерактивный инструмент анализа данных вполне возможен в JS и может потребоваться миллионы точек данных. Один из вариантов заключается в том, чтобы по умолчанию было меньше разрешения (например, ежедневно вместо каждого второго измерения) или меньшего окна (один день против десятилетия секунд). Но по мере того, как пользователь продолжает исследовать набор данных, потребуется больше и больше данных, что может привести к повреждению базовой ОС на стороне агента.

Хорошее решение - пойти с некоторым разумным первоначальным допущением. Позвольте открыть некоторые популярные веб-приложения и перейдите в dev tools - profiles - снимки кучи, чтобы посмотреть:

  • FB: 18.2 MB
  • GMail: 33 МБ
  • Google+: 53,4 МБ
  • YouTube: 54 МБ
  • Карты Bing: 55 МБ

Примечание: эти числа включают узлы DOM и объекты JS в куче.

Похоже, что тогда люди принимают 50 МБ ОЗУ за полезный веб-сайт. После того как вы построите свое DOM-дерево, заполните ваши структуры данных тестовыми данными и посмотрите, сколько из них нормально хранить в ОЗУ.

Используя аналогичные измерения при настройке эмуляции устройства в Chrome, можно увидеть потребление одних и тех же сайтов на планшетах и ​​телефонах BTW.

Так я достиг 100 МБ на рабочем столе и 20 МБ на мобильных телефонах. Считается также разумным. Конечно, для случайного тяжелого пользователя было бы неплохо иметь возможность вырезать максимальную кучу до 2 ГБ.

Теперь, что вы делаете, если перекачивать все эти данные с сервера каждый раз слишком дорого?

Одно дело - использовать кэш приложений. Он создает мягкие головные боли для управления версиями, но позволяет хранить около 5 МБ данных. Вместо того, чтобы хранить данные, полезно использовать код приложения и ресурсы в нем.

Кроме того, у нас есть три варианта:

Из них FileSystem наиболее поддерживается и может использовать значительную часть хранилища.

Ответ 2

В Chrome ответ: Sure!

Перейдите в консоль и введите:

performance.memory.jsHeapSizeLimit; // will give you the JS heap size
performance.memory.usedJSHeapSize; // how much you're currently using

arr = []; for(var i = 0; i < 100000; i++) arr.push(i);
performance.memory.usedJSHeapSize; // likely a larger number now

Ответ 3

Поскольку веб-приложение не может иметь доступ к какой-либо связанной с системой информации (например, доступный объем памяти), и поскольку вы не хотите, чтобы пользователи вручную задавали свои параметры производительности, вы должны полагаться на решение который позволяет вам получать такую ​​информацию о пользовательской системе (доступной памяти), не спрашивая их. Кажется невозможным? Ну, почти...

Но я предлагаю вам сделать следующее: создать апплет Java, который автоматически получит доступный размер памяти (например, с помощью Runtime.exec(...) с соответствующей командой), при условии, что ваш апплет подписан, и вернуть эту информацию на сервер или напрямую на веб-страницу (с помощью JSObject, см. http://docs.oracle.com/javafx/2/api/netscape/javascript/JSObject.html).

Однако это предполагает, что ваши пользователи могут запускать Java-апплет в своих браузерах, что не всегда так. Поэтому вы можете попросить их установить на своих компьютерах небольшую часть программного обеспечения, которая будет определять, сколько памяти должно использовать ваше приложение без сбоев браузера, и отправит эту информацию на ваш сервер. Конечно, вам придется переписать эту небольшую программу для каждой ОС и архитектуры (Windows, Mac, Linux, iPhone, Android...), но проще, чтобы переписать все приложение, чтобы получить некоторые представление. Это своего рода промежуточное решение.

Я не думаю, что есть простое решение. Будут некоторые недостатки, что бы вы ни выбрали. Помните, что веб-приложения не имеют репутации быстрой работы, поэтому, если производительность критическая, вам следует рассмотреть возможность создания традиционного настольного приложения.