Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If <code>MyCollection</code> is going to be garbage collected anyway, then you shouldn't need to dispose it. Doing so will just churn the CPU more than necessary, and may even invalidate some pre-calculated analysis that the garbage collector has already performed.</p> <p>I use <code>IDisposable</code> to do things like ensure threads are disposed correctly, along with unmanaged resources.</p> <p><strong>EDIT</strong> In response to Scott's comment:</p> <blockquote> <p><em>The only time the GC performance metrics are affected is when a call the [sic] GC.Collect() is made"</em></p> </blockquote> <p>Conceptually, the GC maintains a view of the object reference graph, and all references to it from the stack frames of threads. This heap can be quite large and span many pages of memory. As an optimisation, the GC caches its analysis of pages that are unlikely to change very often to avoid rescanning the page unnecessarily. The GC receives notification from the kernel when data in a page changes, so it knows that the page is dirty and requires a rescan. If the collection is in Gen0 then it's likely that other things in the page are changing too, but this is less likely in Gen1 and Gen2. Anecdotally, these hooks were not available in Mac OS X for the team who ported the GC to Mac in order to get the Silverlight plug-in working on that platform.</p> <p>Another point against unnecessary disposal of resources: imagine a situation where a process is unloading. Imagine also that the process has been running for some time. Chances are that many of that process's memory pages have been swapped to disk. At the very least they're no longer in L1 or L2 cache. In such a situation there is no point for an application that's unloading to swap all those data and code pages back into memory to 'release' resources that are going to be released by the operating system anyway when the process terminates. This applies to managed and even certain unmanaged resources. Only resources that keep non-background threads alive must be disposed, otherwise the process will remain alive.</p> <p>Now, during normal execution there are ephemeral resources that must be cleaned up correctly (as @fezmonkey points out <em>database connections, sockets, window handles</em>) to avoid unmanaged memory leaks. These are the kinds of things that have to be disposed. If you create some class that owns a thread (and by owns I mean that it created it and therefore is responsible for ensuring it stops, at least by my coding style), then that class most likely must implement <code>IDisposable</code> and tear down the thread during <code>Dispose</code>.</p> <p>The .NET framework uses the <code>IDisposable</code> interface as a signal, even warning, to developers that the this class <em>must</em> be disposed. I can't think of any types in the framework that implement <code>IDisposable</code> (excluding explicit interface implementations) where disposal is optional.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COCalling Dispose is perfectly valid, legal, and encouraged. Objects that implement IDisposable usually do so for a reason. The only time the GC performance metrics are affected is when a call the GC.Collect() is made.
      singulars
    2. COFor many .net classes, disposal is "somewhat" optional, meaning that abandoning instances "usually" won't cause any trouble so long as one doesn't go crazy creating new instances and abandoning them. For example, the compiler-generated code for controls seems to create fonts when the controls are instantiated and abandon them when the forms are disposed; if one creates and disposes thousands of controls , this could tie up thousands of GDI handles, but in most cases controls aren't created and destroyed that much. Nonetheless, one should still try to avoid such abandonment.
      singulars
    3. COIn the case of fonts, I suspect the problem is that Microsoft never really defined what entity is responsible for disposing the "font" object assigned to a control; in some cases, a controls may share a font with a longer-lived object, so having the control Dispose the font would be bad. In other cases, a font will be assigned to a control and nowhere else, so if the control doesn't dispose it nobody will. Incidentally, this difficulty with fonts could have been avoided had there been a separate non-disposable FontTemplate class, since controls don't seem to use the GDI handle of their Font.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload