Почему «используется» улучшение производительности C #

Думаю, вы думаете о финализаторах. Финализаторы используют синтаксис деструктора в C # и автоматически вызываются сборщиком мусора. Финализаторы подходят только для очистки неуправляемых ресурсов.

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

Обнаружение на самом деле сложнее, чем кажется. Что, если у вас есть такой код:

  var mydisposable = new...
  AMethod(mydisposable);
  // (not used again)

Возможно, какой-то код в AMethod сохраняет ссылку на myDisposable.

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

• Может быть, myDisposable подписывается на событие внутри AMethod (тогда издатель события содержит ссылку на myDisposable)

• Может быть, AMethod порождает другой поток

• Возможно, mydisposable становится «заключенным» анонимным методом или выражением lamba внутри AMethod.

Все это затрудняет абсолютную уверенность в том, что ваш объект больше не используется, поэтому Dispose позволяет разработчику сказать: «Хорошо, я знаю, что теперь запускать мой код очистки безопасно);

Имейте в виду, что dispose не освобождает объект - это может сделать только сборщик мусора.(У GC действительно есть волшебство, чтобы понять все сценарии, которые я описал, и он знает, когда очищать ваш объект, и если вам действительно нужен код для запуска, когда GC не обнаруживает ссылок, вы можете использовать финализатор). Однако будьте осторожны с финализаторами - они предназначены только для неуправляемых выделений, которыми владеет ваш класс.

Подробнее об этом читайте здесь: http://msdn.microsoft.com/en-us/magazine/bb985010.aspx и здесь: http://www.bluebytesoftware.com/blog/2005/04/08/DGUpdateDisposeFinalizationAndResourceManagement.aspx

Если вам нужна неуправляемая очистка дескрипторов, прочтите также о SafeHandles.

Сборка мусора (хотя и не имеет прямого отношения к IDisposable, это то, что очищает неиспользуемые объекты) не так проста.

Позвольте мне немного переформулировать это. Автоматический вызов Dispose() не так прост. Это также не приведет к прямому увеличению производительности. Подробнее об этом чуть позже.

Если бы у вас был следующий код:

public void DoSomeWork(SqlCommand command)
{
    SqlConnection conn = new SqlConnection(connString);

    conn.Open();

    command.Connection = conn;

    // Rest of the work here
 }

Как бы компилятор узнал, когда вы закончили использовать объект conn? Или если вы передали ссылку какому-то другому методу, который удерживал его?

Явный вызов Dispose() или использование блока using четко указывает на ваше намерение и заставляет все очистить должным образом.

Теперь вернемся к производительности. Простой вызов Dispose() на объекте не гарантирует увеличения производительности. Метод Dispose() используется для "очистки" ресурсов, когда вы закончили работу с объектом.

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

Если оставить решение о вызове Dispose() на усмотрение компилятора, это лишит его ясности и усложнит отладку утечек памяти, вызванных неуправляемыми ресурсами.

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

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

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

Неустойчивые объекты также могут вызывать беспокойство.

Кроме того, с помощью () {....} более читабелен и интуитивно понятен, что многого стоит с точки зрения ремонтопригодности.

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

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

Посмотрите на MSDN Artilce для C# Using Statement Оператор using - это просто сокращение, чтобы не делать try и finally во многих местах. Вызов dispose не является функцией низкого уровня, как сборка мусора.

Как вы можете видеть, using переводится как.

{
  Font font1 = new Font("Arial", 10.0f);
  try
  {
    byte charset = font1.GdiCharSet;
  }
  finally
  {
    if (font1 != null)
      ((IDisposable)font1).Dispose();
  }
}

Как компилятор узнает, куда поместить блок finally? Вызывает ли он его при Garbage Collection?

Garabage Collection не происходит, как только вы покидаете метод. Прочитайте эту статью о Garbage Collection, чтобы лучше понять ее. Только после того, как на объект не будет ссылок. Ресурс может быть связан гораздо дольше, чем нужно.

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

Мне кажется, что G.C. трудно понять, что вы больше не будете использовать эту переменную позже в том же методе. Очевидно, что если вы покинете метод и не сохраните дальнейших ссылок на переменную, то G.C. избавится от нее. Но использование using в вашей выборке говорит G.C., что вы уверены что больше не будете использовать эту переменную после.

Оператор using не имеет ничего общего с производительностью (если только вы не рассматриваете предотвращение утечек ресурсов / памяти как производительность).

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

Затем метод Dispose () отвечает за освобождение всех ресурсов, используемых объектом. Чаще всего это неуправляемые ресурсы, такие как файлы, шрифты, изображения и т. Д., Но они также могут быть простыми действиями по «очистке» управляемых объектов (но не сборкой мусора).

Конечно, если метод Dispose () реализован плохо, оператор using не дает никаких преимуществ.

Я думаю, что OP говорит: «Зачем беспокоиться об« использовании », когда компилятор должен быть в состоянии решить это волшебным образом довольно легко».

Я думаю, что OP говорит, что

public void SomeMethod() 
{ 
    ... 

    var foo = new Foo();

    ... do stuff with Foo ... 


    // Foo isn't use after here (obviously). 
    ... 
} 

должно быть эквивалентно

public void SomeMethod() 
{ 
    ... 

    using (var foo = new Foo())
    {
    ... do stuff with Foo ... 
    }

    // Foo isn't use after here (obviously). 
    ... 
} 

, потому что Foo больше не используется.

Ответ, конечно же, заключается в том, что компилятор не может решить это довольно легко. Сборка мусора (которая волшебным образом называется Dispose () в .NET) - очень сложное поле. Тот факт, что символ ниже не используется, не означает, что переменная не используется.

Возьмем этот пример:

public void SomeMethod() 
{ 
    ... 

    var foo = new Foo();
    foo.DoStuffWith(someRandomObject);
    someOtherClass.Method(foo);

    // Foo isn't use after here (obviously).
    // Or is it?? 
    ... 
} 

В этом примере someRandomObject и someOtherClass могут иметь ссылки на то, что указывает Foo, поэтому, если мы вызовем Foo.Dispose (), они сломаются. Вы говорите, что просто представляете простой случай, но единственный «простой случай», когда то, что вы предлагаете, работает, - это случай, когда вы не вызываете методы из Foo и не передаете Foo или любой из его членов чему-либо еще - эффективно, когда вы вообще не используете Foo, и в этом случае вам, вероятно, не нужно его объявлять. Даже в этом случае вы никогда не можете быть уверены, что какое-то отражение или взлом событий не получило ссылку на Foo только при его создании или что Foo не подключился к чему-то еще во время своего конструктора.

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