987resu
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| Я смотрел (однопроцесс) - труба 500-1000 без ребазы и 300-600 с, вторая цифра после 3ч примерно, сам сделай и посмотри, даже просто хул, а последняя строка большой ребазы выжимает ещё 20мб имено порядком расположения файлов. |
Так я тоже смотрел, и отписался по результатам:
http://forum.ru-board.com/topic.cgi?forum=5&topic=51380&start=720#17
А ещё я почитал про что там эта канитель с рибейзом, чтобы для себя понимасть. И что удивительно, надеюсь таки понял. Я не на все 146% уверен, как именно работает тот длинный rebase, но что-то мне подсказывает, что он всем им прописывает один и тот же адрес загрузки (0x61d60000 вместо дефолтного 0x1000000). А в этом случае она достаточно бессмысленная - т.к., сработает только для первой загруженной dll-ки; для следующей её базовый адрес будет уже занят, и загрузчик затолкает её в первый свободный (снизу, а не за 0x61d60000), с ремапом всех там виртуальных таблиц и прочего. Чтобы был какой-то эффект, надо dumpbin-ом посмотреть, сколько занимает xul.dll, и следующему rebase сдвинуть на эту величину (ну или что там по порядку; вполне возможно, что эти 20 Мб - просто побочный эффект ремапа следующих в порядке загрузки).
Другой вопрос, а в чём вообще от этого смысл в однопроцессе? Не, я понимаю, что межпроцессовая коммуникация несовершенна, и тоже выжирает память, но так-то это совсем уныло, на один раз одно видео в ютупе посмотреть, и упереться в ограничения для одного процесса.
Я так-то наивно полагал, что перемещение к верхним адресам для этого:
Цитата:| Multiple processes that load the same DLL at the same base address share a single copy of the DLL in physical memory. Doing this saves system memory and reduces swapping. |
Типа, когда второму процессу понадобилось, а адрес загрузки (в его виртуальном адресном пространстве) занят чем-то другим - он будет делать свою копию, в отличие от написанного для идеального случая.
Иначе, так-то это всё ниочём. Ну да, только лишь доказывает, что управление памятью внутри настолько безупречное, что до загрузки этой dll-ки они ухитряются её настолько покрошить фрагментацией, что за целым куском для загрузки надо идти на полгига выше...
|
Всего записей: 55 | Зарегистр. 28-07-2024 | Отправлено: 17:37 24-09-2024 | Исправлено: 987resu, 17:50 24-09-2024 |
|
То-то смотрю, что все инстансы за последние несколько дней поотваливались...
