TheBarmaley
Platinum Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Во избежание непоняток и лишних вопросов:
Всё сказанное ниже относится только к работе под Windows XP и НЕ применимо к более новым операционным системам!
Кроме того, все указанные действия неактуальны для тех, кому на расход памяти "глубоко пофиг". 
Отчёт о тестировании повышенного потребления памяти браузерами с рантаймами MS VC 2015-2019
Тестирование проводилось в рамках обсуждения этой проблемы отсюда и далее..
07.06.2021.
Часть №1. Первоначальная проверка проблемы и оценка повышенного расхода памяти.
Условия тестирования:
ОС: Windows XP SP3 х86, объём установленной памяти 4ГБ, режим PAE включён
Браузеры: 360 Extreme Explorer версий 11 (.2251), 12 (.1592) и 13 (.2206) и miniChrome (miniBrowser) 87 (билд 106)
00. эбаут рантайма, который стоял раньше и который использован в текущей проверке:
01. текущая позиция - без рантаймов, удалённых третьего дня, для проверки запущены три тяжёлых:
- верхний = 12.1592 (висит третий день, просто выгрузил все инет-вкладки, кроме расширений, трёх служебных и новой),
- следом 13.2206 (только запущен с двумя вкладками, расширения и новая),
- внизу минхром-87(106 билд) (только запущен, две вкладки - расширения и файлик с букмарками - это у меня новая такая)):
02. то же без рантаймов, но выгружены все три браузера:
03. ставим рантайм из п.00 + запускаем 12 с теми же вкладками:
04. запускаем ещё и 13, с теми же вкладками:
05. пытаемся запустить ещё и минихром - это минут через 5 при интенсивном дрочении винта, 12/13-й начали самовыгружаться:
06. пожалел винт и принудительно убил минихрома (он так и не завёлся, даже фейс не показал, сожрав всю память):
07. выгружаем 12 и 13:
08. запускаем только минихром (те же вкладки):
09. выгружаем минихром, удаляем рантайм и снова запускаем минихром:
10. закрываем минихром и смотрим, что в итоге после всех издевательств и без этих троих осталось:
11. снова запускаем 12-й:
12. добавляем к нему 13-й:
13. добавляем к ним минихром:
14. ну и до кучи ещё и 360-11.2251:
вопчем, к вопросу о "глазах" - сами смотрите/считайте, кто сколько при каком раскладе ест.. 
up 08.06.2021:
часть 2. на основании последних данных по этой проблемке в качестве дополнительного эксперимента.
во избежание различных "типа предъяв" в некорректности эксперимента:
система с момента прошлой проверки НЕ перезагружалась, все запущенные программы (кроме браузера макстон2) НЕ перегружались..
да, сутки прошли, система изменила состояние, это понятно, процессы загружались/выгружались, но суть не в этом..
итак, проверяем дальше:
15. снова установил этот же рантайм И удалил ВСЕ файлы api-ms-win-core-* из папки /%windir%/system32/
исходное - все тестируемые браузеры = выгружены:
разница в доступной памяти между "вчерашним" (п.07) и сегодняшними = порядка 50 м, т.е. в пределах погрешности..
16. снова запускаем все те же 4 браузера (сверху вниз: 12, 13, 11 и минхром):
разница в итоговом между "вчерашними" четырьмя (п.14, без рантайма!) и сегодняшними (с рантаймом) = +500 м (в большую сторону)..
кмк, полгига трудно списать на "погрешность измерения", но настаивать не буду, это уже гораздо менее существенно..)
как видно, отжор памяти в этой части эксперимента намного меньше, чем в прошлом (с установленными рантаймами, п.03,04,05,06)..
и это - с учётом того, что там всего 1/2 (!) браузера, а тут - все 3 линейки 360-х + работающий (!) минихром..)
итого - выводы делаем сами, как/куда копать должно быть примерно понятно.. 
up 09.06.2021:
часть 3. на основании новых данных по этой проблемке в качестве дополнительного эксперимента.
во избежание различных "типа предъяв" в некорректности эксперимента:
система с момента прошлой проверки НЕ перезагружалась, все запущенные программы (кроме браузера макстон2) НЕ перегружались..
да, ещё сутки прошли, система опять изменила состояние, конечно же, процессы загружались/выгружались, но суть не в этом..
главное отличие теста: заменяем установщик из п.00 на последнюю версию под ХР - 14.29.30037:
разница с другими пакетами - в этой версии НЕТ файлов api-ms-win-*.dll, приводящих к лишнему отжору памяти (см 1 и 2).
Цитата:
итак, проверяем дальше:
17. снова удаляем предыдущий рантайм (из п.00) И ставим версию 14.29.30037
исходное - все тестируемые браузеры = выгружены:
разница в доступной памяти между "вчерашним" (п.15) и сегодняшними = порядка 7 м, т.е. в пределах погрешности..
18. снова запускаем все те же 4 браузера (сверху вниз: 11, 12, 13 и минхром-87/билд 106):
разница между "позавчерашними" четырьмя (п.14, без рантайма!) и сегодняшними (с новым рантаймом) = +450 м (в большую сторону)..
разница между "вчерашними" четырьмя (п.16, "старый" рантайм) и сегодняшними (с новым рантаймом) = -100 м в меньшую сторону..
да, результат хуже, чем вообще без рантаймов 2015-2019, но зато сам рантайм стоит без огрызков и прочего шаманства..=)
итак, отжор памяти и в этой части эксперимента намного меньше, чем в прошлом (с установленным рантаймами из п.00 - п.03,04,05,06)..
и это - также с учётом того, что там всего 1/2 (!) браузера, а тут - все 3 линейки 360-х + работающий (!) минихром..)
итого - если не хочется возиться с какими-то ручными настройками - можно просто установить последнюю доступную* версию пакета..
* конечно же, с учётом того, что основная dll (msvcp140.dll) рантайма -версии -14.29.30037 -НЕ -работает -под -Windows -XP.
решение вопросов совместимости отдельных программ в вашей системе с MSVC-2015+ приведено в "итогах" (п.2Б).
up 11.06.2021:
часть 4. на основании дополнительных данных по расходу памяти в качестве бонуса безотносительно к рантаймам.
во избежание различных "типа предъяв" в некорректности эксперимента:
система с момента прошлой проверки НЕ перезагружалась, все запущенные программы (кроме браузера макстон2) НЕ перегружались..
да, ещё два дня прошло, система снова изменила состояние, многие процессы загружались/выгружались, но суть не в этом..
главное отличие теста от части 3: проверяем запуск с флагом --renderer-process-limit=2:
нужен для ограничения числа одиночных процессов, влияет на общий расход памяти при работе с несколькими вкладками одного сайта (домена) в сторону его уменьшения за счёт сведения нескольких процессов в один (краткая матчасть).
итак, проверяем дальше:
19. исходное - все тестируемые браузеры = выгружены:
разница в доступной памяти между "вчерашним" (п.17) и сегодняшними = порядка 18 м, т.е. в пределах погрешности..
20. снова запускаем все те же 4 браузера (сверху вниз: первая пара = 13 и минхром-87, вторая = 11 и 12):
разница между "начальными" четырьмя (п.14, без рантайма) и сегодняшними (новый рантайм и ключ) те же +450 м (в большую сторону)..
разницы между "вчерашними" четырьмя (п.18, "новый" рантайм) и сегодняшними (новый рантайм и ключ) нет (с учётом исходного, п.19)..
результат практически одинаков, выигрыш в копейках за счёт уменьшения числа процессов на пару штук отнесём к погрешности..=)
итак, отжор памяти и в этой части эксперимента показывает независимость стартового отжора от проверяемого ключа.
итого - если не нужны проблемы с одновременным крэшем из-за одного глючного сайта/вкладки - ключ не имеет смысла использовать с целью экономии расхода памяти.. то же самое относится и к другому ключу (--process-per-site, можно использовать на 360ЕЕ-11 на движке 69, в более новых - неприменим), копеечная экономия приведёт к возможным проблемам со стабильностью работы..
На всякий лучай повторю ещё раз - во избежание непоняток и лишних вопросов:
Всё сказанное ниже (и выше) относится только к работе под Windows XP и НЕ применимо к другим операционным системам!
Общий итог по всем тестам и обсуждению (редакция от 11.06.2021):
Варианты решений для снижения повышенного расхода памяти:
(по результатам обсуждения этой проблемы отсюда и далее)
1. наилучший результат даёт полное удаление из системы рантаймов MSVC-2015-2019.
в этом случае отжор памяти будет наименьшим при прочих равных (см. первую часть, п.01-п.14)..
2. варианты решения, если рантаймы в вашей системе нужны для других программ:
2А. следует удалить файлы api-ms-win-*.dll.
эти файлы (всего 40* штук) находятся в папке %windir%/system32/ (и в %windir%/sysWOW64/ для систем х64).
* для решения проблемы отжора лишней памяти в браузерах 360ЕЕ достаточно удалить только два файла из этой группы:
api-ms-win-core-string-l1-1-0.dll и api-ms-win-core-synch-l1-2-0.dll (остальные - на ваше усмотрение).
вместо удаления можно просто переименовать или переместить их из системных папок в любое другое место, это будет полезно..
..в случае, если какая-либо программа требует любые из этих файлов - можно просто скопировать нужные в папку её установки.
также можно удалить в реестре записи об этих dll в ветке HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls
при этом отжор будет больше, чем при отсутствии этого рантайма, но вполне допустим для нормальной работы (см. ч.2, п,15-п.16)..
для понимания, зачем всё это "шаманство" нужно - читаем начиная отсюда, а также здесь, там и тут..
2Б. можно установить последнюю предлагаемую под ХР версию рантаймов: 14.29.30037.
взять её можно на официальном сайте MS (прямые ссылки: x86 / x64), или где-то здесь..)
при этом отжор будет больше, чем при отсутствии рантайма вообще, но меньше, чем в п.2А (см. ч.3, п,17-п.18)..
кроме того, отсутствие в установщике этой версии рантайма файлов api-ms-win-*.dll приводит к тому, что они
НЕ будут "цепляться" и к другим модулям и приложениям, у которых есть такая зависимость (напр., флэш или DRM-модули),
что, в свою очередь, также снижает общее потребление памяти по аналогии с п.2А (см. тут, здесь и там).
важное замечание:
у этого варианта есть "минус" - сам рантайм msvcp140.dll версии 14.29.30037 НЕ работает под Windows XP,
это может приводить к ошибкам программ, которые запрашивают и используют эту библиотеку из системной папки.
для решения этой проблемы можно самостоятельно заменить указанный dll-файл в системной папке (%windir%/system32)..
..или копировать все необходимые dll-файлы непосредственно в папку такой "неработающей" программы..
в качестве источника для замены можно использовать любой работающий в ХР рантайм вплоть до версии 14.28.29213
найти эту версию можно здесь или где-то там, прочитать о проблеме неработоспособности можно, например, здесь..
3. для любителей хардкора: вариант с ручной правкой файлов* для выгрызания ссылок на файлы api-ms-win-*.dll
* это не единственный файл, в частности, для 360-13.0.2206 придётся искать/править в 10 файлах, потому и хардкорЪ..))
в общем случае этот вариант тоже имеет право на существование, хотя и связан с гораздо большими затратами времени..
этот метод также может быть использован для создания собственных сборок (напр., для финальных версий браузеров),
это даёт пользователям этих сборок возможность обойтись без каких-либо "шаманств" при минимальном расходе памяти.
однако, следует помнить, что это решение может быть затруднено из-за срабатывания защиты файлов самим браузером..
кроме того, не исключена и ситуация, когда лишнюю память будут расходовать сторонние подключаемые модули..
4. дополнение по использованию ключей, ограничивающих число процессов с целью снижения расхода памяти
речь о ключах --process-per-site (для 360ЕЕ-11) и --renderer-process-limit=2 (читать здесь и тут, смотреть ч.4, п.19-п.20).
общий итог - можно спорить о нужности/ненужности в отдельных случаях и "ловить мегабайты" на разнице в процессах, но..
..в обшем и целом - экономия памяти при этом приводит к нестабильности работы браузера и увеличивает вероятность сбоев.
исходя из соображений надёжности работы, применение этих ключей не может быть рекомендовано всем и каждому.
|
