JavaScript
Client optimization
Browsers
Comments 12
+4
Попытка управлять руками памятью в системах с автоматическим управлением (и кучей эвристик в этом управлении), как правило, ни к чему хорошему не приводит. В Хроме дела не «хуже», чем в Фаерфоксе, а, вероятно, оптимальнее — если нет дефицита памяти _в данный конкретный момент времени_ (никто не запрашивает), то можно и отложить тяжёлый запуск коллектора, накопив бОльший блок для освобождения. В ситуации с дефицитом памяти этот график наверняка станет другим. Вся подобная ручная возня с памятью тянется мифологией и сказаниями предков ещё из тёмных времён MS-DOS и сплетается с патологическими формами «я лучше производителей платформы знаю как должно быть». Может, и действительно лучше, но тогда стОит заняться написанием патчей для этой платформы, а не конструированием костылей на уровне выше.
+3
Я в статье привёл два примера, когда стратегия «вся свободная память — моя память» (кстати, популярная как раз в эпоху MS-DOS) не всегда работает. Дополню.

Допустим, браузер забил всю оперативку мусором. Другое приложение тоже ориентируется на количество свободной памяти. Оно видит, что памяти нет, и выделяет для некой своей операции буфер пониженного размера, что приводит к понижению производительности. Или выделяет такой же объём, допустим гигабайт, а операционная система, чтобы удовлетворить требование, перемещает часть занятой памяти (занятой мусором) в файл подкачки. В этот момент браузер видя, что памяти маловато, наконец начинает убирать мусор, только уже поздновато…

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

В идеальном мире, где у людей куча свободного времени — да. В реальном, написать костыль + пнуть разработчиков в багтрекере намного быстрее.
0
Наверное, вам стОит изучить, как устроена виртуальная память (и когда приложение в современных операционных системах получает сообщение о невозможности выделения памяти, и как соотносятся RTL-malloc'и с системными вызовами выделения памяти). Всё сильно сложнее, чем в MS-DOS, и приложения легко могут запрашивать памяти больше, чем есть реально планок в компьютере (пока не начнут использовать эту память — тут уже включается подкачка или жёсткие эксепшны о недостатке). «Чем меньше цифры в ГУЕ менеджера памяти, тем лучше» — культ карго чистой воды, отзывчивость системы достигается не снижением этих цифр, а стабилизацией их значений (уменьшением количества изломов на гребёнке графика, если говорить грубо, но это тоже очень грубо и не должно быть единственным аспектом оптимизации).
0
Сейчас проверил, как Chrome 58 ведет себя в условиях нехватки памяти. Во время работы расширения запустил в фоне утиль, который в цикле выделяет, заполняет и тут же освобождает почти всю свободную оперативную память. Результат: в файл подкачки ушло примерно 400 МБ, кэш винды упал до нуля, а процесс с расширением… все также бодро лопает почти 500 МБ. Может бы и дальше продолжил расти, у меня сейчас нет времени долго тесты гонять.

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

Если система стоит на HDD, то в вышеприведенной ситуации об отзывчивости можно только мечтать.
-2
Несколько запущенных копий расширения довольно быстро его исчерпают и приведут либо к «падению» процесса, либо к проблемам воспроизведения видео

Как минимум спорное утверждение.

Да и вообще: chrome + 15 расширений + overдомного вкладок + отладка прямо в браузере и как-то все норм.

+2
Как минимум спорное утверждение.

Я привёл в статье ссылку на chromium issue 713344, в которой процесс разрастался до 3.5 ГБ. Если запустить тот пример (переместив с диска в инет) в нескольких вкладках, то процесс падает из-за недостатка памяти. Причём падает 64-битный браузер, похоже у него где-то в коде есть лимит на 4 ГБ на процесс.
0
Но это баг GC, который надо исправлять, а не «особенность» его стратегии.
Я заводил похожий issue 610158, сразу признали багом и кинулись чинить.
Правда, дальнейшую судьбу бага я так и не понял :) Вскоре появилась пометка Fixed, но в текущей стабильной версии 58 он проявляется всё равно. За год изменения не докатились из dev до stable?
+1
За год изменения не докатились из dev до stable?

omahaproxy.appspot.com говорит, что коммит попал в версию 52. Если ошибка до сих пор присутствует, то наверное нужно создать новую issue. А может будет достаточно отписаться в старой.
+1

К сожалению тут зависит от системы, а точнее от конфигурации компа и приложений. Я, помнится, оставил свой ноут (8GB, ubuntu 16.04) с запущенным в хроме вк на сообщениях (по моим наблюдениям самый активный и стабильный сжиратель памяти). Через часов 9-10 пришёл, еле переключив на tty1, запустил htop и офигел — кроме браузера я оставил ещё свою ide от JB, которая написана на java, вечном пинаемом за сожранную память. Тк вот, ide крутила девовский nodejs на 20% памяти. Ещё примерно 10% на себя забрала сама ось и её графика. Остальные 70 были безжалостно сожраны хромом…
Пришлось вырубать с кнопки.

+2
Если в Firefox сборщик мусора достаточно неплохо справляется, то в Chrome он явно отлынивает от работы
И правильно делает!

Вы смотрите на график с точки зрения пользователя PC, который подключен к розетке и возможно страдает от нехватки RAM. В этом случае «оптимизация» GC выглядит круто!

Но с другой стороны, из-за вашего решения, пользователи смартфонов и ноутбуков начинают судорожно искать зарядное устройство и розетку, потому как вместо того, чтобы «отлынивать» браузер в панике пинает GC, чтобы тот освободил целых ~20 Мб памяти!

Не стоит забывать, что уже сейчас в вебе больше 50% — мобильные пользователи, и дальше эта цифра будет только рости. Возможно ваш плагин и работает для десктопных браузеров, но они так же запускаются на ноутбуках, которым важна автономность. Автономность 1-3 часа без розетки — это очень больно :-(
0
Ничто не мешает браузеру менять поведение GC в зависимости от типа питания. В моем случае питание было от розетки. И расширение предназначено для настольных компов.

Но идея интересная. Можно вызывать navigator.getBattery() и не использовать трюки если питание от аккумулятора.
0
GC занимается не только сборкой, но и выделением памяти и просто так взять и поменять алгоритм на лету — это не тривиальная задача.
Да, изменить частоту сборки — в теории можно, но в этом случае ноутбук будет сильнее греться и даже куллером жужжать начнет — это тоже неприятный опыт для пользователя, по-моему, даже более неприятный, чем небольшие тормоза какого-то приложения.

ps: в любом случае, прежде чем внедрять такой подход стоит лишний раз подумать, стоит ли так сильно усложнять систему (поддержку) и какой профит от этого будет?
Only those users with full accounts are able to leave comments. , please.