Здравствуйте, Aggtaa, Вы писали:

A>Те цифры, которые я приводил — размеры памяти, выделенной под модули януса. ДЛЛки, ресурсы, данные,

Что то сомневаюсь я про данные. Ты размеры длл-ек померил. А он вообще смысла не имеют.

A>Что касается ЖЦ — все кучи януса вместе взятые сейчас 9792028 байт. Сколько из них реально нужно для работы — я не в курсе, как узнать.

Ну, то есть ты понял, что дотнет тут не причем?

A>CLR затребовал для януса 108546160 байт, из них 54839728 реально используется.

Это не ЦЛР. Это всего виртуальной памяти.

A> Т.е. потери только для CLR составляют 52 метра.

Какие нафиг потери? Это условно занятое место на жестком диске — своп + длл-ки.

A> Плюс по мелочам на левые библиотечки. Можно считать, что половину своей памяти янус ест необоснованно. Может, придет пора — освободит, может — нет.

Можно перестать придумывать.

A>Цифирки взяты из Process Explorer и PsTools от Sysinternals и из TaskManager от Microsoft.

А ты возми нормальный дотнетный мемори-профайлер (ссылки тут давали не раз) и погляди. Неплохо подхдят девпартнерские утилиты. Смотреть же дотнетные процессыц средством предназначенным для просмотра анменеджед-процессов довольно бессмысленно.

Здравствуйте, Aggtaa, Вы писали:

AVK>>Размер имаджа. Непонятно зачем.
A>Сделаем проще — А как надо?

А надо мерять размер реально используемой физической памяти.

Здравствуйте, Aggtaa, Вы писали:

A>Ну вот у меня нет виртуалки. 2 гига физической памяти и все.

Ну, что я тебе могу сказать. Кому закон не писан знашь?

Здравствуйте, Aggtaa, Вы писали:

A>Какая разница программе, сколько ее страниц физически существует в памяти?

Огромная.

Здравствуйте, Aggtaa, Вы писали:

A>Обычно за мной это не водится.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Aggtaa, Вы писали:

AVK>>>А как коррелируют размер имаджа и объем занимаемой памяти?
A>>А кто говорил про размер образов? Я мерял выделенную память.
AVK>Интересно, как вобще можно узнать сколько в хипе заняла отдельная dll?
Длл или ее данные? Если первое, то не знаю. Если второе, то в большинстве случаев никак. Не все данные принадлежат какой-то длл.

AVK>>>microsoft.mshtml.dll например вобще кода практически не содержит, поэтому память не выделяет.
A>>Ок. Тогда зачем под нее выделили почти 8 метров?
AVK>Под ее имадж выделили 8М адресного пространства, потому что файл имеет такой размер.
Супер. Я вызвал CreateFileMapping. Ну, или не я, а kernel со своим CreateProcess — не важно. Задал я MaximumSize или она взялась из размера модуля — тоже не важно. Важно то, что под отображение этого модуля выделили N страниц памяти и все эти N страниц памяти реально заняты, освободить их не получится, пока отображение не закроют через CloseHandle или еще как. Ок. Я согласен, что можно делать MapViewOfFile и читать этот файл по кускам. Но разве исполняемые файлы грузятся так?

Или вот допустим загрузили мы картинку в память. и заняла она у нас M страниц памяти. Нет, лучше K — она, зараза, тяжелая. Опять же, пока мы не скажем DeleteObject, эта память потеряна безвозвратно.

Вообще, если программа сказала MEM_COMMIT — эту память можно считать занятой, или еще нет?
Может, просто я чего-то недопонимаю в принципах выделения памяти Windows? Я совсем не против наверстать упущенное. Расскажешь, как правильно?

Здравствуйте, VladD2, Вы писали:

A>>Ну вот у меня нет виртуалки. 2 гига физической памяти и все.
VD>Ну, что я тебе могу сказать. Кому закон не писан знашь?
-1.

Здравствуйте, VladD2, Вы писали:

A>>Какая разница программе, сколько ее страниц физически существует в памяти?
VD>Огромная.
Объясни.

Здравствуйте, VladD2, Вы писали:

VD>Имено этим ты и страдаешь. Иначе бы не стал выключать файл подкачки называя это выключением виртуальной памяти.
"Если бы он требовал столько памяти, то занял бы виртуалку и лег бы на своп." (с) ???

Здравствуйте, VladD2, Вы писали:

A>>Те цифры, которые я приводил — размеры памяти, выделенной под модули януса. ДЛЛки, ресурсы, данные,
VD>Что то сомневаюсь я про данные. Ты размеры длл-ек померил. А он вообще смысла не имеют.
Супер. Это ничего, что я не мерял размеры длл-ек.

A>>Что касается ЖЦ — все кучи януса вместе взятые сейчас 9792028 байт. Сколько из них реально нужно для работы — я не в курсе, как узнать.
VD>Ну, то есть ты понял, что дотнет тут не причем?
Ну вот ведь а. Gen 0 heap size + Gen 1 heap size + Gen 2 heap size + Large object heap size = дотнет тут нипричем. Ок.

A>>CLR затребовал для януса 108546160 байт, из них 54839728 реально используется.
VD>Это не ЦЛР. Это всего виртуальной памяти.
Ууу... .Net CLR total reserved bytes — это всего виртуальной памяти. Пусть так.

A>> Т.е. потери только для CLR составляют 52 метра.
VD>Какие нафиг потери? Это условно занятое место на жестком диске — своп + длл-ки.
Ой, блин... "Условно занятое место на диске"?

A>> Плюс по мелочам на левые библиотечки. Можно считать, что половину своей памяти янус ест необоснованно. Может, придет пора — освободит, может — нет.
VD>Можно перестать придумывать.
Я постараюсь.

A>>Цифирки взяты из Process Explorer и PsTools от Sysinternals и из TaskManager от Microsoft.
VD>А ты возми нормальный дотнетный мемори-профайлер (ссылки тут давали не раз) и погляди. Неплохо подхдят девпартнерские утилиты. Смотреть же дотнетные процессыц средством предназначенным для просмотра анменеджед-процессов довольно бессмысленно.
Кажется, разговор зашел в тупик.

Здравствуйте, Aggtaa, Вы писали:

AVK>>Под ее имадж выделили 8М адресного пространства, потому что файл имеет такой размер.
A>Супер. Я вызвал CreateFileMapping. Ну, или не я, а kernel со своим CreateProcess — не важно. Задал я MaximumSize или она взялась из размера модуля — тоже не важно. Важно то, что под отображение этого модуля выделили N страниц памяти и все эти N страниц памяти реально заняты, освободить их не получится, пока отображение не закроют через CloseHandle или еще как.

Плохо ты знаешь как работает Win32. Никакой памяти реально выделятся не будет до первого обращения к выделенному адресному пространству. И выделяется память постранично, т.е. кусками по 4Кб, а не сразу вся. Более того — пока не будет произведена запись, физическая страница памяти будет одна на все образы файла для всех процессов.

A>Или вот допустим загрузили мы картинку в память. и заняла она у нас M страниц памяти. Нет, лучше K — она, зараза, тяжелая. Опять же, пока мы не скажем DeleteObject, эта память потеряна безвозвратно.

Вот с картинкой это действительно так.

Здравствуйте, Aggtaa, Вы писали:

VD>>Это не ЦЛР. Это всего виртуальной памяти.
A>Ууу... .Net CLR total reserved bytes — это всего виртуальной памяти. Пусть так.

Не виртуальной памяти, а зарезервированного адресного пространства.

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Под ее имадж выделили 8М адресного пространства, потому что файл имеет такой размер.
A>>Супер. Я вызвал CreateFileMapping. Ну, или не я, а kernel со своим CreateProcess — не важно. Задал я MaximumSize или она взялась из размера модуля — тоже не важно. Важно то, что под отображение этого модуля выделили N страниц памяти и все эти N страниц памяти реально заняты, освободить их не получится, пока отображение не закроют через CloseHandle или еще как.
AVK>Плохо ты знаешь как работает Win32. Никакой памяти реально выделятся не будет до первого обращения к выделенному адресному пространству. И выделяется память постранично, т.е. кусками по 4Кб, а не сразу вся.
Если посмотрть в kernel32.dll, то видно:

CreateFileMapping(..., SEC_READONLY | SEC_COMMIT, ...);
...
MapViewOfFile(..., FILE_MAP_READ, 0, 0, 0);

Жаль, нет у меня исходников Windows, можно было бы без многоточий обойтись.
Как такой код может выделить не всю память сразу, а после первого обращения?

AVK>Более того — пока не будет произведена запись, физическая страница памяти будет одна на все образы файла для всех процессов.
Это в случае, если MapViewOfFile был вызван с флагом FILE_MAP_COPY. Если без него, то физическая страница памяти так и останется одна на все процессы, разве нет?

Здравствуйте, AndrewVK, Вы писали:

VD>>>Это не ЦЛР. Это всего виртуальной памяти.
A>>Ууу... .Net CLR total reserved bytes — это всего виртуальной памяти. Пусть так.
AVK>Не виртуальной памяти, а зарезервированного адресного пространства.
CLR.

Зарезервированного адресного пространства всего у януса 529,028К.

Здравствуйте, Aggtaa, Вы писали:

A>Если посмотрть в kernel32.dll, то видно:
A>

A>CreateFileMapping(..., SEC_READONLY | SEC_COMMIT, ...);
A>...
A>MapViewOfFile(..., FILE_MAP_READ, 0, 0, 0);
A>

Жаль, нет у меня исходников Windows, можно было бы без многоточий обойтись.
A>Как такой код может выделить не всю память сразу, а после первого обращения?

Вам бы батенька Рихтера почитать, там все написано.

AVK>>Более того — пока не будет произведена запись, физическая страница памяти будет одна на все образы файла для всех процессов.
A>Это в случае, если MapViewOfFile был вызван с флагом FILE_MAP_COPY. Если без него, то физическая страница памяти так и останется одна на все процессы, разве нет?

Для образов да, поскольку запись в эти сегменты памяти просто запрещена.

Здравствуйте, fddima, Вы писали:

_>>никто не спорит что он много требует. но 60 мб или чуть больше, как например ваш софт-это немного до??я. дох??я для программки чтения форумов
F> тем не менее это одна из самых удобных программ что я видел когда-либо...

Я бы сказал, что она уютная. А уютным софт бывает просто крайне редко. Последнее, что я помню, был ГолДед

Здравствуйте, Чеширский Кот, Вы писали:

ЧК>Я бы сказал, что она уютная. А уютным софт бывает просто крайне редко. Последнее, что я помню, был ГолДед
Супер Я тоже его помню. Хотя должен сказать, что памятью тебе нуна срочно заняться... а то довольно большой провал образовался (в шутку)

Здравствуйте, Andre, Вы писали:

A>А все-таки, как я могу выкачать все форумы?
A>Способ №2: Найти в своем городе человека с большой базой и напоив его пивом получить себе базу

863375360 байт.
И в отпуск я вышел. Жду

Здравствуйте, Aggtaa, Вы писали:

VD>>Имено этим ты и страдаешь. Иначе бы не стал выключать файл подкачки называя это выключением виртуальной памяти.
A>"Если бы он требовал столько памяти, то занял бы виртуалку и лег бы на своп." (с) ???

Нда. Полное непонимание.

Здравствуйте, fddima, Вы писали:

F>Здравствуйте, dimitry_dimitry, Вы писали:

F> тем не менее это одна из самых удобных программ что я видел когда-либо...

Самая удобная програма для убивания рабочего времени и по эфективности опережает "сапёр" и "тетрис" на 237%