Создает ли использование делегата мусор?
2 ответа
Делегат сам по себе является объектом, поэтому, если вы создаете делегат, возможно, для анонимного метода, и передаете его на выполнение другому методу, и не сохраняйте делегат для использования в будущем , тогда да, , что будет производить мусор.
Например, это:
collection.ForEach(delegate(T item)
{
// do something with item
});
В этом случае создается новый объект делегата, но помимо вызова ForEach он не упоминается и, следовательно, имеет право на сборку мусора.
Однако вызов делегатов сам по себе не производит мусора, равно как и вызов любого другого метода того же типа. Например, если вы вызываете делегат, который принимает параметр Object , передавая значение Int32 , это значение будет помещено в рамку, но это произойдет, если вы вызвали обычный метод. путь тоже.
Таким образом, использование делегатов должно быть нормальным, но чрезмерное создание объектов делегатов будет проблемой.
Правка : Хорошая статья об управлении памятью для Xbox и XNA находится здесь: Производительность управляемого кода на Xbox 360 для XNA: Часть 2 - Сборщик мусора и инструменты . Обратите внимание на эту цитату:
Так как же контролировать задержку сборки мусора? Как и NetCF для устройств, Xbox GC не связан с поколениями. Это означает, что каждая коллекция представляет собой полную коллекцию в управляемой куче. Таким образом, мы обнаруживаем, что задержка сборки мусора примерно линейна по отношению к количеству живых объектов… затем добавляем к этому стоимость уплотнения кучи. Наши тесты показывают, что разница между глубокими иерархиями объектов и мелкими несущественными, поэтому в основном имеет значение количество объектов. Маленькие предметы также, как правило, обходятся дешевле, чем большие.
Как видите,
В среде рабочего стола мусор фактически бесплатен . Вот о чем вы хотите беспокоиться, так это о том, сколько не-мусора вы производите. Вспомните, как работает сборщик мусора: сначала он помечает все известные объекты, затем снимает отметку со всех живых объектов и сжимает живые объекты. Дорогостоящий шаг - «снятие отметок с живых объектов». Уничтожить мусор - дешево; идентификация живых объектов является дорогостоящей, и эта стоимость зависит от количества живых объектов, которые у вас есть (и сложности их эталонной топологии), а не от количества мертвых объектов, которые у вас есть.
Однако в XBOX и других компактных фреймворках сборщик мусора запускается довольно часто и запускается чаще при создании новых распределений, так что да, вы тоже правы, что беспокоитесь о создании мусора. Вы хотите, чтобы динамический набор оставался небольшим (чтобы сделать коллекцию дешевой) и не выделять новые (потому что это запускает коллекции).
Создание делегат выделяет память, но вызывает ] one - это не что иное, как вызов метода с именем Invoke для класса. Делегат - это не что иное, как класс с методом Invoke, который сразу вызывает другой метод при его вызове.
В любом случае, если у вас есть проблема с производительностью памяти, то правильное решение do - это получить профилировщик памяти и использовать его для анализа вашей программы. Бросать наугад в размышлениях о том, происходит ли то или иное выделение памяти, - все равно что пытаться прополить свой сад ножницами для ногтей; это занимает много времени и не на самом деле достигаю своих целей. Воспользуйтесь профилировщиком, чтобы проанализировать свою производительность и определить проблемы, а затем исправить их.