ЗимарглDima T.... Запустил свою поделку консольную на C# - 1,4 Мб.
...
Опять же все зависит о задачи. Насколько критично сэкономить 10-100 Мб ОЗУ, фремворк это ж не только занимание памяти, но и облегчение и ускорение разработки.
...

Ты не тот скорее всего параметр смотришь. Минимальный футпринт дНет приложения занимает примерно 10Мб в памяти. Я писал выше, что смотреть в диспетчере задач.

Я сходу не смогу придумать адекватный и _воспроизводимый_ академический метод.
Когда смотрел для себя - просто засекал дельту свободной памяти при выгрузке отработавшего приложения.

В Win7 Это совпадает с показателем "Память - Рабочий набор".
Объем же фреймворка, подлинкованного но не загруженного можно увидеть в "Память - выделенная память". Но боюсь, для языков с широкм использованием динамического связывания это не годится.
Смотрю на свою программулину (вообще она для поиска одинаковых файлов на диске, но без параметров просто выдает справку о командной строке и висит ждет нажатия на кнопку)
Рабочий набор 6,7 Мб
Выделенная память 4,8 Мб
Частный рабочий набор 1,4 Мб

Мутно немного написано, но куда надо смотреть зависит от задачи. Например
1. у нас одна копия проги то заняли Рабочий набор, т.е. там и данные и код проги, и фрэймворк.
2. у нас N процессов одной и той же проги, то займет она Рабочий набор + (N - 1) * Частный рабочий набор.
3. у нас N разных прог, но на одном фрэймворке, фрэймворк в реальной памяти тоже будет однократно размещен, поэтому будет как в п.2 плюс размер самих прог (без фрэймворка)

ЗимарглНасколько критично 50Мб Озу на процесс вебсервера можешь посмотреть в статье про multitenant JVM выше по топику.
По сути это п.2. т.е. фрэймворк реальную память займет один раз. Другой вопрос сколько займет каждый процесс во время работы, но это уже не только от фрэймворка зависит, но и от кривизны рук разработчика.

AdxDima TAdx,

я тебя понять не могу к чему ты все адресованное мне написал. У нас с Зимарглом было обсуждение проблемы подкачки с диска (заметь мы друг-друга поняли), а тут ты со своими постами в какую-то другую сторону, я честно не понимаю к чему ты это все написал.
Давай проще, начни с конца: пиши сразу к чему ты ведешь, что доказываешь, что я по твоему не понимаю. А я тебе отвечу так оно или нет.

Без проблем. Вы оба исходите по некоторым вопросам из неверных предположений. Я пытался это объяснить.
1) Простое приложение на .NET грузит диск (эта самая подкачка) ничуть не больше чем написанное на C++ безо всякого .NET
Независимо от размера всего фреймворка.
2) В .NET есть много механизмов загрузки сборок. Можно загрузить ее в память сразу, и потом уже не происходит обращения к диску.
3) Ошибки страниц не стопроцентный показатель, зависит от приложения.
4) Насчет кэширования Вы писали, замечу только, что своппинг генерит ошибки страниц со страшной силой.
1. Согласен. Обратного не утверждал.
2. Согласен. Обратного не утверждал.
3. У тебя просто недопонимание как все устроено, почитай книжку про устройство виртуальной памяти, адресное пространство процесса и т.п.
Пример (кратко): процесс А спроецировал в свое адресное пространство файл (пофиг какой EXE, DLL, TXT), затем произошло обращение к первому байту (пофиг как: данные прочитать или код там выполнить) происходит исключение, менеджер памяти его перехватывает, читает с диска первые 4 кб файла в реальную память (вот она страница), подставляет эту реальную память просессу и возвращает управление проге, прога дальше работает. Запускается прога Б, проецирует этот же файл, обращается к первому байту, происходит исключение, счетчик ошибок страниц увеличивается, но менеджер памяти видит что эта страница уже есть в реальной памяти, поэтому он НЕ читает с диска, он просто подсовывает ее в процесс Б. Т.е. два процесса А и Б реально используют одни и теже 4 кб реальной памяти.
4. Свопинг это результат ошибок страниц, т.е. когда данных/кода нет в памяти они читаются с диска. Кроме того есть еще запись в своп для освобождения памяти. Читай книжку :)

Dima T2. у нас N процессов одной и той же проги, то займет она Рабочий набор + (N - 1) * Частный рабочий набор.
Затестил. Подтверждается моя теория.

Рабочий набор 6,1 Мб
Выделенная память 4,8 Мб
Частный рабочий набор 1,4 Мб
Запустил 100 процессов, наблюдал в диспетчере параметр "Физическая память (Мб) всего свободно". Для 100 процессов уменьшилось на 162-166 Мб. Т.е. ~1,6 Мб на процесс.

ЗимарглДокажи. Я предъявлял ошибки страниц при использования интерфейса. И их гораздо больше в дНет программе, чем в написанной С++ и даже на Яве.
Тот же тест 18100590 каждый из 100 процессов показывает 1500 ошибок страниц, но это не означает 150000 обращений к диску.
Выше писал
Dima TПример (кратко): процесс А спроецировал в свое адресное пространство файл (пофиг какой EXE, DLL, TXT), затем произошло обращение к первому байту (пофиг как: данные прочитать или код там выполнить) происходит исключение, менеджер памяти его перехватывает, читает с диска первые 4 кб файла в реальную память (вот она страница), подставляет эту реальную память просессу и возвращает управление проге, прога дальше работает. Запускается прога Б, проецирует этот же файл, обращается к первому байту, происходит исключение, счетчик ошибок страниц увеличивается, но менеджер памяти видит что эта страница уже есть в реальной памяти, поэтому он НЕ читает с диска, он просто подсовывает ее в процесс Б. Т.е. два процесса А и Б реально используют одни и теже 4 кб реальной памяти.
Я к тому что ты некорректно трактуешь значение "ошибки страниц". По твоему 1 ошибка = 1 чтение с диска. Это не так.

Тот же тест на С

Рабочий набор 2,0 Мб
Выделенная память 0,6 Мб
Частный рабочий набор 0,5 Мб
Ошибок страниц 533
Запустил 100 процессов, наблюдал в диспетчере параметр "Физическая память (Мб) всего свободно". Для 100 процессов уменьшилось на 48-52 Мб. Т.е. ~0,5 Мб на процесс.

Как бы не намного разница: .Net занял на 1 Мб больше.

Что касается ошибок страниц, так они точно сответствуют формуле Рабочий набор*256, т.к. 1 Мб = 256 страниц. Т.е. в данном случае это просто показатель сколько используется страниц в виртуальном адресном пространстве данного процесса.

Надо какой-то тест изобрести, близкий к реальности, но не очень тривиальный. Линуксы предлагаю пока в стороне оставить.

Вариант теста: сгенерить текстовый файлик с иерархическим списком но в разнобой, затем отсортировать, сохранить в другой файл.
типа23.44.1. опдлываопдл
1.2. павлыопыавлопж
...
формат строки: X.X....X.{пробел}текст
где X 1-2 знака. Количество Х-ов до 5. Общая длина строки до 100 байт.

Замеряем:
1. Время на загрузку
2. Время на сортировку
3. Время на сохранение

Размер исходного файла подобрать чтобы 5-10 сек молотило.

Могу генератор написать чтоб файлик у всех одинаковый был. Тогда результат на корректность можно будет по CRC проверить.

AdxУ меня этот же код ...
Объяснимо: у меня VS2010 у тебя вроде 2013 (если не путаю). .Net соответственно 4.0 и 4.5.
Значит MS не сидит сложа руки, допиливает и что приятно - в нужную сторону :)
AdxВсе, прекращаю оффтопить )
Присоединяюсь

ЗимарглDima T,
нужно больше использования фреймворка, а не простых операций.
Согласен. Тест синтетический. Но он показывает умение конкретного фрэймворка подстроиться под написаный на нем код.

Но это второстепенно, даже третьестепенно. Главная задача фрэймворка увязать возможности нижнего уровня (С, Асм) с простотой написания кода. Яркий пример FoxPro, на котором я и пишу восновном, подобный тест даже не буду выкладывать, проиграет по всем параметрам. Но на фоксе можно легко делать такие вещи, которые вызовут глубокую зависть конкурентов. Недавно демонстрировали мою поделку одной достаточно большой компании, сбежался весь ИТ-отдел, смотрел и утверждал что такое невозможно. Вроде элементарные вещи показывали когда по слову " О брикос" находит все "Абрикосы". Любой гугл это умеет. А это просто помесь фокса и Си в правильных пропорциях :)

maytonА если я введу "Абрамс" - найдет "Абрикос" ? :)
Нет. Количество ошибок ограничено. Читай про расстояние Левенштейна. Хотя ты и так знаешь не читая :)
Следующий шаг - использовать релевантность.

ЗЫ Правда получилось что "желтый" ~= "белый"