TheBarmaley
Platinum Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
..вопчем, потестил с крайней 14.29.30037 - чуть лучше, чем просто с удалением апи-мс*, но хуже, чем вообще без рантаймов..
результаты с пикчами докинул в "фотосессию" + добавил туда же общие итоги трёхдневного "мозгового штурма", пока как-то так:
Во избежание непоняток и лишних вопросов:
Всё сказанное ниже относится только к работе под 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).
общий итог - можно спорить о нужности/ненужности в отдельных случаях и "ловить мегабайты" на разнице в процессах, но..
..в обшем и целом - экономия памяти при этом приводит к нестабильности работы браузера и увеличивает вероятность сбоев.
исходя из соображений надёжности работы, применение этих ключей не может быть рекомендовано всем и каждому.
если что - это = черновой вариант выводов, несмотря на "немилость шерифа" обсуждение можно продолжить и подрихтовать.. 
..надо, однако, за это дело выпить.. всем сопричастным и приложившимся - 
..а потом можно ещё и с лисой попробовать опять поковыряться..))
|
