Re: How much do you leave to VB.Net GARBAGE COLLECTION???

On Jul 24, 1:19 am, Alan Mailer <clarityas...@xxxxxxxxxxxxx> wrote:
As an ex-VB6 person, I remember often having to make sure that my code
set to "Nothing" objects I created throughout my programs.

My cursory reading of some VB.Net info is that this may no longer be
as necessary due to the Garbage Collection capability.

I wanted to hear from you experts.  I notice VB.Net has methods like
"Dispose" and such.  So, if Garbage Collection works, when, if ever do
you write in code that specifically destroys objects you create?

Thanks in advance for any enlightenment you'd care to share on this
subject.

Basically, the only objects you have to worry about cleaning up are
those that implement IDisposable and have a Dispose method. The GC
does an excellent job cleaning up all the others.

For IDisposable objects, when the GC runs it will go through and see
that this objects no longer have any references to them and it will
call their Finalizer. From the Finalizer, the Dispose method will be
called and then all (if any) explicit cleanup that needs to be done on
the object will be done. Then, the next time that the GC runs, the
object will be released from memory. Just remember, that if a
Disposable object is not disposed it will have to go through two
collections of the GC.

In order to speed up this GC action, Microsoft recommends that you
call Dispose on any method that has it. This will cause immediate
cleanup of all (if any) resources that the object says needs cleaned
up. It has the added benefit (even when no objects are cleaned up by
the Dispose) of only having the object go through a single GC
collection, as properly implemented Dispose patterns call
GC.SuppressFinalizer which stops the above mentioned behavior.

This is a very controversial topic and opinions and tempers tend to
flare about it. Here are three excerpts from the book "Improving .NET
Application Performance and Scalability: Patterns and Practices" that
might be of use to you:

"The reason you want to avoid finalization is because it is performed
asynchronously and unmanaged resources might not be freed in a timely
fashion. This is especially important for large and expensive
unmanaged resources such as bitmaps or database connections. In these
cases, the classic style of explicitly releasing your resources is
preferred (using the IDisposable interface and providing a Dispose
method). With this approach, resources are reclaimed as soon as the
consumer calls Dispose and the object need not be queued for
finalization. Statistically, what you want to see is that almost all
of your finalizable objects are being disposed and not finalized. The
finalizer should only be your backup."

"Call Close or Dispose on classes that support it."

"If the managed class you use implements Close or Dispose, call one of
these methods as soon as you are finished with the object. Do not
simply let the resource fall out of scope."

Thanks,

Seth Rowe [MVP]
http://sethrowe.blogspot.com/
.

Relevant Pages

  • Re: Is Dipose( ) a contractual obligation, if you provide one?
    ... You're at least saying "it'd be a really good idea for you to call Dispose ... relinquish its resources at an explicit point." ... and the finalizer should take care. ... a UEntity unmanaged object requires a USession unmanaged ...
    (microsoft.public.dotnet.languages.vc)
  • Re: " //Clean Up managed resources " f&*ck
    ... The finalizer is called by the GC. ... time (such as releasing internal unmanaged resources). ... Since Dispose ... it is about 'managed resource'. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: About speed
    ... IDisposable needs a finalizer, and most code that I see that implements ... void IDisposable.Dispose ... call GC.SupressFinalizer inside their Dispose method. ... then disposed explicitly (using IDispose), ...
    (borland.public.delphi.non-technical)
  • RE: newbie: implementing destructors
    ... finalizer to your class means it takes longer to garbage collect (look up on ... have some 3rd party DLL which internally allocates a chunk of memory, ... environment is not aware of this memory so at no point will it clean up this ... let's call it Dispose for now which you can call ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Question on implementing IDisposable
    ... have dealth with the unmanaged resources and before you take your ... This class does not implement a finalizer ... The overloaded Dispose which takes a bool argument should be made ... Then, the base class can implement IDispose, so ...
    (microsoft.public.dotnet.languages.csharp)
Loading