Каковы преимущества управляемой памяти, если .NET увеличивает размер приложения?

Question

Я давно не программирую и плохо знаком с C / C ++.Я всегда использовал C # в прошлом, но я перешел на собственный код, чтобы написать свое первое приложение Win32 API.Я начал в C, но все больше приходил в бешенство, пытаясь работать без классов.

Я начал переносить некоторые из C на C ++.Первоначально у меня была настройка проекта как VC ++ с использованием .NET 4. Примерно на 25% пути портирования я запускал программу в режиме отладки.Я был потрясен.По словам диспетчера задач, программа использует более чем в два раза больше памяти, чем версия C.Затем я удалил .NET-проект и был еще более удивлен: используя только STL, моему приложению требовалось 33% памяти, необходимой для воплощения .NET.Вот цифры:

Использование памяти
Полное приложение в C: ............... 940kb
25% Порт вVC ++ /. NET4: ...... 2,1 МБ
25% Порт в C ++: ................... 700 КБ

Если я отложу в сторону другие функции .NET, мне будет интересно, каково преимущество управляемой памяти, если она утраивает объем памяти.Это вытеснение утечек?Безопасные указатели?

Спасибо

Answer 1

Каждый думает о сборе мусора неправильно .Если в системе отсутствует нагрузка на память, у CLR практически нет причин постоянно выполнять этапы сборки мусора.Так что это не так.Это не означает, что память эффективно просочилась, просто сборщик мусора еще не успел его очистить.

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

Answer 2

Часть памяти, которую вы видите, будет принадлежать среде выполнения .Net Framework.

Сборка мусора помогает избежать больших накладных расходов на программирование, таких как запоминание освобождения памяти или освобождения объектов. Я много программировал на C, Objective C и C #, и могу с уверенностью сказать, что хотя сборка мусора не решает всех проблем, она снимает с меня большую ответственность и позволяет мне сосредоточиться на логике, а не на поиске инструкция по выпуску exra.

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

Я должен сказать, что хотя сборка мусора великолепна, она не идеальна и имеет свои ограничения в .Net, особенно когда речь идет о неуправляемом коде, то есть отсутствие вызова dispose может оставить память в памяти до завершения. Циклы сбора также могут быть дорогостоящими, так как вся деятельность приостановлена ​​на время сбора мусора.

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

Answer 3

Сборка мусора и никаких свисающих ссылок, наверное.И отражение.

Answer 4

Вы смотрите на использование памяти в диспетчере задач? Это не точный способ для профилирования вашего приложения: в эту цифру будет включено много несущественных данных.

Для управляемого приложения, я ожидаю увидеть увеличение из-за загрузки среды выполнения вообще. Более того, сборщик мусора .NET не агрессивно обращается с памятью: он пытается отложить сборы до тех пор, пока не кончится память.

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

Сборщик мусора избегает фрагментации, сжимая память каждый раз, когда выполняет распределение: он перемещает объекты в памяти рядом друг с другом, оставляя большую дыру в конце. Последующее выделение может быть быстрым из-за этого: распределителю выделенной памяти не нужно просматривать список дыр, но он может идти прямо до конца кучи. [1]

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

[1] Это не относится к куче, используемой для больших объектов (больше чем около 85 КБ). Куча больших объектов работает как обычная куча malloc / free.

Answer 5

Ваш объем памяти настолько мал, что, вероятно, это объясняет ваши интуитивные результаты. В обеих системах есть накладные расходы. Они проводят аналогичный тест с примерно 1 ГБ памяти, и вы должны увидеть, что, по вашему мнению, произойдет.

Answer 6

Я тоже новичок в программировании DotNet, но давно занимался программированием на C / C ++. Из того, что я понимаю, вы не используете DotNet, если вы обеспокоены использованием памяти. Любая платформа, имеющая промежуточный уровень, такой как Java или C #, будет использовать больше памяти. Компромисс по сравнению с простым программированием на C / C ++, как объясняли другие, заключается не только в сборке мусора и управлении памятью, но и в более богатых библиотеках. Я бы потратил как минимум в три раза больше времени, если бы мне пришлось делать то, что я делаю сейчас без DotNet. Не запоминать больше ошибок и обрабатывать их. Также сборщик мусора, который очищает память, когда ему действительно не нужно, занимает процессорное время, которое могло бы быть выделено вашему процессу, и заставляет ваш процесс ждать. Таким образом, дополнительная нагрузка на память не является плохой вещью.