Какой разумный объем памяти для .NET-приложения?

Это зависит от того, что делает приложение. 20 - 25Мб для меня не так много.

Я только что создал очень простое приложение Windows Form с очень небольшим объемом, и это заняло 19–20 МБ. Я предполагаю, что это, вероятно, примерно минимальный объем памяти, который занимает приложение .NET Forms.

Этот вопрос похож на вопрос «сколько яблок вы можете положить в комнату» ...

Сначала я бы возразил, спросив «насколько большие яблоки» ...?

Тогда я отвечал бы "Насколько велика комната" ...?

Когда вы ответили на эти вопросы, можно дать оценку грубый. Хотя имейте в виду, что даже приложение "Hello World" в .Net (и Java тоже в этом отношении) может занимать от пары килобайт до нескольких сотен терабайт (теоретически), поскольку сборщики мусора в основном построены таким образом, что они распределяются очень быстро. экстремальные объемы памяти в пуле в зависимости от объема доступной памяти. Таким образом, на компьютере с ограниченным объемом памяти приложение .Net WinForms может занимать небольшие объемы, в то время как в системе с огромным объемом свободной памяти может потребоваться (теоретически) терабайты даже для "Hello World" ...

20-25Мб это ничего.

В любом случае .Net framework не всегда сразу перерабатывает оперативную память. Со временем я видел, как приложения вырастали до нескольких сотен МБ ОЗУ во время «дорогостоящего» процесса, а затем просто оставались там даже после завершения «дорогостоящего» процесса. Однако это заблуждение. Приложение не использовало эту оперативную память. Просто сборщик мусора еще не видел необходимости собирать много старой оперативной памяти. Если бы операционная система нуждалась в этой оперативной памяти, будьте уверены, что она будет собрана. Идея о том, что приложение должно использовать не более нескольких сотен килобайт, просто неприменима в среде удалось - для процессов операционной системы, да. Возможно, для нативных приложений. Но не управляемый код. В противном случае вы просто получите системы с полным ГБ или более ОЗУ, которые просто бездействуют.

Это довольно разумно, да. Выделить немного больше памяти дешевле, чем агрессивно пытаться уменьшить размер кучи с помощью более частой сборки мусора.

Нет, это просто возмутительно. Вы называете себя программистом? Боже мой, мужик. Когда я только начинал, я мог уместить пятнадцать аппликаций на одну перфокарту (которую, кстати, мне приходилось пробивать парой ржавых кусачков для ногтей). Все они завершились за пятнадцать циклов ЦП и фактически СОЗДАЛИ память из ничего.

Тебе должно быть стыдно. Немедленно уйти в отставку.

Существует потенциально веская причина для отказа: что, если ваш клиент использует ваше приложение в среде терминальных служб, а дюжина или более пользователей совместно используют 4 ГБ ОЗУ? Добавьте свои 20-25 МБ к Outlook 30+, IE 20+, Word 25+ и Excel 25+, умножьте на количество пользователей терминала, и, надеюсь, вы увидите, откуда они мощь.

Я думаю, что в наши дни 20-25 МБ - это вполне разумно. Если у вас сотни мегабайт, это может быть другая история. Но все зависит от обстоятельств.

Что делаешь? Оправдывает ли это использование памяти примерно на 20 полнометражных романов? Это определенно ваше приложение, а не только накладные расходы времени выполнения .net? На рассматриваемой машине не хватает памяти? Это снижает производительность?

На этот, а также на тысячу и еще один вопрос вам нужно ответить :) Я лично считаю, что это смехотворно огромный объем памяти ... но потом я работаю на мобильных телефонах, где 20 МБ - это максимум, с которым мне когда-либо сходит с рук. максимальный размер кучи :)

Что они на самом деле подразумевают под оперативной памятью? Это рабочий набор, частный рабочий набор, виртуальная память и т. д. И т. Д.? Я только что запустил довольно простое приложение .Net, и оно занимало 21 МБ рабочего набора, это 21 МБ ОЗУ. Но его частный рабочий набор составляет всего 4 МБ, поэтому около 17 МБ занято системой и разделяемыми библиотеками, которые будут использоваться, даже если мое приложение не было загружено.

Затем я проделал с приложением довольно интенсивную работу с памятью, и частный рабочий набор увеличился до 28 МБ. Затем я переключился на другое приложение, интенсивно использующее память, и вот мой частный рабочий набор теперь составляет 8 МБ, несмотря на то, что память не была освобождена.

Использование ОЗУ приложением чрезвычайно сложно измерить, и еще труднее решить, является ли использование памяти «слишком большим» (помимо чего-то возмутительного, конечно).

Если ваш клиент не использует тщательно продуманные измерения счетчиков производительности для определения различных типов использования памяти, вы на самом деле не знаете, сколько памяти ваше приложение использует на их компьютерах.

На самом деле у вас нет проблем с памятью. У вас есть потенциально сложная проблема коммуникации, зависящая от технических знаний клиента. Но ОЗУ дешево звучит немного фальшиво и может быть не лучшим подходом.

Если ваши пользователи используют диспетчер задач для проверки использования памяти вашим приложением, скорее всего, они смотрят на столбец Использование памяти. Как говорит Стивен Мартин, это вводит в заблуждение, поскольку этот столбец фактически показывает полный рабочий набор приложения. Он состоит из:

• Рабочий набор частный - резидентные страницы, которые являются частными только для вашего процесса.
• Рабочий набор разделяемый - резидентные страницы, которые могут использоваться другими процессами.
• Рабочий набор общий - резидентные страницы, которые в данный момент используются совместно с другими процессами. Это подмножество совместно используемого рабочего набора.

В этом случае вы можете сыграть небольшую шутку, вручную уменьшив полный рабочий набор вашего приложения до его частного / общего рабочего набора. Это делается с помощью вызова Win32 API SetProcessWorkingSetSize (GetCurrentProcess (), -1, -1). Это то, что Windows будет делать в любом случае, когда системе не хватает памяти, но контроль, когда это происходит, позволяет вам разделить полный рабочий набор вашего .NET-приложения на его частный / общий рабочий набор. Это число обычно намного меньше.

Насколько меньше? Сворачивание приложения на панель задач делает то же самое, поэтому вы можете проверить, не меняя код.

Если вы неоднократно вызывали недоумение из-за объема памяти, используемого вашим приложением, вам следует хотя бы немного взглянуть, действительно ли вам нужна эта сумма или это просто накопленная неэффективность. Уменьшение объема памяти часто также приводит к увеличению скорости, а это, в свою очередь, увеличивает удовлетворенность клиентов. Часто такие жалобы также могут указывать на другие недостатки, которые с точки зрения пользователя просто выглядят как раздутые.