И, конечно, Высокий звук + F4 для закрытия вещей.
Глядя на тот факт, что вы читаете целые файлы WMA в массив, я бы сказал, что эти объекты массива размещаются в куче больших объектов. Это отдельная куча, которая управляется способом, более похожим на malloc (поскольку сжатие сборки мусора неэффективно при работе с большими объектами).
Пространство в куче больших объектов собирается в соответствии с другими правилами, а не учитывайте количество основных поколений, и тогда вы не увидите разницы в количестве коллекций между тестами 1 и 2, даже если память используется повторно (все это s собирается именно объект Array, а не базовые байты). В тесте 3 вы принудительно собираете коллекцию каждый раз вокруг цикла - в нее включается куча больших объектов, поэтому использование памяти процессом не увеличивается.
TaskManager - не лучший инструмент для этого. Используйте профилировщик CLR или для чего-нибудь простого, используйте WriteLine, чтобы показать GC.GetTotalMemory ()
.
Основная цель сборки мусора - распределение и освобождение большого количества небольших объектов. Если вы хотите изучить это, напишите что-нибудь, что создает много (небольших) строк или около того. Убедитесь, что вы знаете, что означает «GC поколений».
В вашем текущем эксперименте используется куча больших объектов (LOH), которая имеет совершенно другой набор правил и проблем.
Дайте вам ссылку, которая, как мне кажется, может быть вам полезна.
http://msdn.microsoft.com/en-us/magazine/ee309515.aspx
-Joe Ю
Использование памяти, которое вы просматриваете через диспетчер задач, предназначено для процесса. Помните, что среда CLR управляет памятью от имени вашего приложения, поэтому вы, как правило, не увидите, как использование кучи GC напрямую отражается на использовании памяти процессом.
Выделение и освобождение памяти не являются бесплатными, поэтому очевидно, что среда CLR попытается оптимизировать это, чтобы снизить затраты. Таким образом, когда объекты собираются из кучи, вы также можете видеть, а можете и не видеть освобождение памяти для ОС.