Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » 360 Extreme Explorer | другие браузеры компании Qihoo

Модерирует : gyra, Maz

Maz (18-09-2021 11:48): 360 Extreme Explorer | другие браузеры компании Qihoo (Часть 4)  Версия для печати • ПодписатьсяДобавить в закладки
На первую страницук этому сообщениюк последнему сообщению

   

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).

Цитата:
Действительно, библиотеки api-* вызывают увеличенное потребление памяти на XP. Они относятся к так называемым наборам API, появившихся c Windows 7. Данные библиотеки - пустышки, ничего не реализовывают, только указывают, что реализации экспортируемых ими функций находятся в других библиотеках.

 
итак, проверяем дальше:
 
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+ приведено в "итогах" (п.).
 


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).
   общий итог - можно спорить о нужности/ненужности в отдельных случаях и "ловить мегабайты" на разнице в процессах, но..
   ..в обшем и целом - экономия памяти при этом приводит к нестабильности работы браузера и увеличивает вероятность сбоев.
   исходя из соображений надёжности работы, применение этих ключей не может быть рекомендовано всем и каждому.

Всего записей: 12940 | Зарегистр. 07-06-2006 | Отправлено: 06:42 07-06-2021 | Исправлено: TheBarmaley, 13:23 11-06-2021
   

На первую страницук этому сообщениюк последнему сообщению

Компьютерный форум Ru.Board » Компьютеры » Программы » 360 Extreme Explorer | другие браузеры компании Qihoo
Maz (18-09-2021 11:48): 360 Extreme Explorer | другие браузеры компании Qihoo (Часть 4)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2020

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru