Удаляет ли управляемые объекты производительность в .Net?

Question

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

Я видел этот ответ на вопрос, который не получил высокого голоса, но так ли это? Если да, то как?

Нет, это не так. Я согласен с Аарона. Кроме того, Microsoft рекомендует в середине 2003 года на веб-трансляции, которую представил Дон Бокс, каждый разработчик .Net должен располагать своими собственными объектами, независимо от того, являются они управляемыми или неуправляемыми, поскольку это повышает производительность кода на 20%. Если все сделано правильно, это может значительно улучшить производительность. Так что это основной навык, который каждый разработчик .net должен знать и использовать.

Answer 1

Вы просто не можете Dispose управляемой памяти так же, как вы можете вызвать Dispose для освобождения файловых дескрипторов и т. Д. Единственная вещь, которая может очистить управляемую память - это сборщик мусора.

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

Возможность не беспокоиться о времени жизни объекта в большинстве случаев является одним из преимуществ C # - почемуВы бы хотели избавиться от этого, заставив каждый класс реализовать IDisposable?Вы действительно хотите сами управлять "собственностью" и временем жизни?

Я подозреваю, что вы неправильно прочитали (по общему признанию несколько неясный) ответ, который вы цитировали в своем вопросе.Я не верю, что он выступает за избавление от всех объектов - я считаю, что он выступает за то, чтобы явно исключить экземпляры типов, которые уже реализуют IDisposable.Это не имеет ничего общего с чисто управляемыми типами, которые почти никогда не реализуют IDisposable.

Answer 2

Как отметил Джон Скит, этот код плохого дизайна кода:

 public class SomeClass : IDisposable
    {
        private string SomeData;

        public void LoadFileIntoMemory(string filename)
        {
            using (var sr = new StreamReader(filename))
            {
                SomeData = sr.ReadToEnd();
            }
        }
        public void DoSomethingWithDataInMemory()
        {
            //whatever
        }
        public void Dispose()
        {
            SomeData = null;
        }
    }

    class Program
    {
        public static void Main()
        {
            using (var sC = new SomeClass())
            {
                sC.LoadFileIntoMemory("somefile");
                sC.DoSomethingWithDataInMemory();
            }
        }
    }

Гораздо лучше просто сделать это

 public class SomeClass
    {
        private string SomeData;

        public void LoadFileIntoMemory(string filename)
        {
            using (var sr = new StreamReader(filename))
            {
                SomeData = sr.ReadToEnd();
            }
        }
        public void DoSomethingWithDataInMemory()
        {
            //whatever
        }
    }

    class Program
    {
        public static void Main()
        {
            var sC = new SomeClass();
            sC.LoadFileIntoMemory("somefile");
            sC.DoSomethingWithDataInMemory();
            sC = null;
        }
    }

IDisposable должен строго реализовываться, когда ваш класс использует некоторые ресурсы, которые не будут очищены, если переменная для экземпляра класса установлена ​​в нуль :). Все управляемые ресурсы будут очищены при установке пустого экземпляра (при запуске gc).

Answer 3

Во-первых, вызывая методы Dispose, он никоим образом не намекает GC на необходимость выполнения каких-либо специальных действий. Утилизация - это обычный метод, как и любой другой.

Волшебный соус - это то, что делает Dispose, а именно освобождает ресурсы, которые больше не нужны.

Правило № 1 для объектов IDisposable - вызывать Dispose, когда вы закончите с ними. Да, GC может в конечном итоге очистить память, но если объекты все еще связаны с другими, которые все еще используются, они останутся. Утилизация также очищает неуправляемые ресурсы, которые имеют решающее значение, такие как подключения к БД, файловые дескрипторы, блокировки и т. Д. Их, безусловно, необходимо закрыть как можно скорее.

Короче говоря, если вы создали экземпляр объекта IDisposable, избавьтесь от него по завершении.

Да, стоит вызвать Dispose, но, как я уже говорил ранее, это означает, что объекты могут быть не связаны друг с другом, что позволяет GC освободить их при следующем запуске. Это также означает, что неуправляемые ресурсы могут быть немедленно освобождены. Еще одна победа. Утечки памяти и ресурсов могут сильно снизить производительность, а также может произойти сбой приложения, если он станет слишком экстремальным!

Возможно, разработчик защищал важные ресурсы, поэтому, пожалуйста, не пытайтесь угадать его!

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

Answer 4

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