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

Пара моментов:

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

Нет четкого и очевидного механизма того, как компилятор может обрабатывать IDisposable объекты в коде. Что делает его кандидатом на автоматическую утилизацию, а что нет? Если экземпляр (или может) быть представлен вне метода? Ничего не сказать, что только потому, что я передаю объект другой функции или классу, я хочу, чтобы его можно было использовать за пределами метода.

Рассмотрим, например, шаблон фабрики, который принимает Stream и десериализует экземпляр класса.

public class Foo
{
    public static Foo FromStream(System.IO.Stream stream) { ... }
}

И я называю это:

Stream stream = new FileStream(path);

Foo foo = Foo.FromStream(stream);

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

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

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

В конце концов, есть две причины (по соглашению) для реализации IDisposable для типа.

1. Вы используете неуправляемый ресурс (это означает, что вы выполняете вызов P / Invoke, который возвращает что-то вроде дескриптора, который должен быть освобожден другим вызовом P / Invoke)
2. В вашем типе есть экземпляры IDisposable, которые следует удалить по истечении срока жизни этого объекта.

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

Сборка мусора (хотя она и не связана напрямую с 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() компилятору снизит этот уровень ясности и значительно затруднит отладку утечек памяти, вызванных неуправляемыми ресурсами.

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

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

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

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

Взгляните на MSDN Artilce для инструкции использования C #. просто кратчайший путь, чтобы избежать попытки, и, наконец, в выделенных местах. Вызов удаления - это не функция низкого уровня, такая как сборка мусора.

Как видите, using переведено на.

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

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

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

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

C ++ поддерживает это; они называют это «семантикой стека для ссылочных типов». Я поддерживаю добавление этого в 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, причина в том, что вам нужна возможность немедленно удалить его. Мол, прямо сейчас немедленно. Такие конструкции, как соединения с базой данных, не просто одноразовые, потому что им нужно выполнить некоторую особую работу, когда они оказываются в мусоре, - это еще и потому, что их мало.

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

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

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

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

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

Я думаю, что 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.