Dispose Overkill?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I exhaustively dispose/close anything database related and have managed to
control connection leaks.

However, I was wondering about the necessity to use Dispose on non-database
resources.

1. Take this code:
Sub X ()
Dim oItem as DataGridItem
For Each oItem In ctlMembers.Items
Call DoSomething(oItem)
Next
End Sub

The DataGridItem supports a Dispose method. Should I be using it?
Also, should I be setting oItem = Nothing

2. I have an object that was written by a 3rd party that didn't seem to
cause memory leaks when used in VB6. It doesn't have an explicit cleanup
method like Dispose. Do you think it is still getting cleaned up when used
in .Net.

Thanks =)
 
Shawn Brock said:
I exhaustively dispose/close anything database related and have managed to
control connection leaks.

However, I was wondering about the necessity to use Dispose on non-database
resources.

1. Take this code:
Sub X ()
Dim oItem as DataGridItem
For Each oItem In ctlMembers.Items
Call DoSomething(oItem)
Next
End Sub

The DataGridItem supports a Dispose method. Should I be using it?
Click to expand...

Only if you "own" the DataGridItem, which in this case it doesn't sound
like you do. (It also only makes sense when you've definitely finished
with the item, which again doesn't particularly look like it's the case
here.)
Also, should I be setting oItem = Nothing
Click to expand...

No, that would have no effect.
2. I have an object that was written by a 3rd party that didn't seem to
cause memory leaks when used in VB6. It doesn't have an explicit cleanup
method like Dispose. Do you think it is still getting cleaned up when used
in .Net.
Click to expand...

I wouldn't like to say, to be honest.
 
Shawn,

Almost every object used in Net has the dispose method. (Not all).

It derives from system.ComponentModel.Component
http://msdn.microsoft.com/library/d...rfsystemcomponentmodelcomponentclasstopic.asp

This classes derives from it and of course all classes that derives from
those.
http://msdn.microsoft.com/library/d...stemcomponentmodelcomponentclasshierarchy.asp

Therefore when dispose is not overloaded as with the connection, than you
should in my opinion have to ask yourself why you do it. The result of
calling it, does often not more than the sentence a += 0; Although it does
not harm of course when you place this even a million times in your program.

The benefit can be, that when the GC starts working and if it is about a
kind of globaly placed object, it is possible that it needs less time to
release the memory for that.
(If there is a reference to or from an object the GC will never release it,
with or without dispose)

I hope this gives an idea.

Cor
 
Thank you folks for your quick and insightful response.
I went from being an MCSD in VB to feeling like a complete Novice in .Net.
Things are starting to come together, but I have some ASP.NET work that is
dying strange deaths.

Thanks again!
 
Cor Ligthert said:
Almost every object used in Net has the dispose method. (Not all).
Click to expand...

I think that's a bit of an overstatement.

I wrote a quick program to find all the public types in selected
assemblies, and see how many support IDisposable. Here are the results:

mscorlib: 60/903
System.Configuration.Install: 6/14
System.Data: 29/181
System.Data.OracleClient: 8/28
System.Design: 43/102
System.DirectoryServices: 3/22
System: 35/475
System.Drawing: 28/168
System.EnterpriseServices: 3/104
System.Management: 8/67
System.Messaging: 7/46
System.Runtime.Remoting: 2/26
System.Security: 0/21
System.ServiceProcess: 5/18
System.Web: 79/321
System.Web.Services: 8/143
System.Windows.Forms: 79/331

Overall: 403/2970

If you think that's an unrepresentative set of assemblies, let me know
which ones should be considered instead. (Of course, it's possible that
my program has a bug - let me know if you want me to post it.)

A lot of the types used in GUIs, for IO, and for database access
implement IDisposable - but there's a lot more to the framework than
that. (Also, you usually don't need to explicitly dispose of GUI
objects as everything tends to be disposed when the top-level form gets
disposed.)
 
Jon,
I wrote a quick program to find all the public types in selected
assemblies, and see how many support IDisposable. Here are the results:
Click to expand...

I will change my writing about this, I was struggling a little bit with the
text when I wrote this.

I was thinking about something as, "the normally most often used classes in
Net", this will probably make my intention with this writing better and I
shall use that next time.

Thanks for making me attend on that and giving me that figure "more than
15%", I will probably use that as percentage than as well to make it more
clear.

Cor
 
Cor Ligthert said:
I will change my writing about this, I was struggling a little bit with the
text when I wrote this.

I was thinking about something as, "the normally most often used classes in
Net", this will probably make my intention with this writing better and I
shall use that next time.
Click to expand...

But even then I'd disagree with you. It entirely depends on what you're
doing - in my day-to-day work I use *far* more non-disposable types
than disposable types.
Thanks for making me attend on that and giving me that figure "more than
15%", I will probably use that as percentage than as well to make it more
clear.
Click to expand...

I'm not sure it *does* make it clearer, but it's up to you, of course.

I'm also not sure where overloading comes into whether or not you
should call Dispose.
 
Jon,

I'm also not sure where overloading comes into whether or not you
should call Dispose.
Click to expand...

I think that than you have not to ask yourself why you do it, as I wrote,
but than you can read it.

:-)

Cor
 
Back
Top