This is getting way off topic but a little trivia for anyone who is interested.
Actually setting of local objects to null at the IL level is good in a few cases. The one that comes to mind off the top of my head is when you are using a pinned local . The C# compiler actually generates this setting to null for you if you look at the generated IL when you use a fixed statement (the fixed statement creates a pinned local). The reason why this is important is that the pin applies for the duration of the method as far as the GC is concerned, it is not done through a table like most things. By setting it to null immediately after the end of the fixed statement it allows the GC to no longer consider what it is pointing to to be pinned. Cheers, Greg On 9/6/07, Russell Collins <[EMAIL PROTECTED]> wrote: > 1. Every object has a finalizer as well as a constructor in .NET > whether you declare it or not. Most people do not explicitly put > finalizers in so when the Garbage Collector runs, it executes an empty > finalizer. In the normal course of events, when an object is getting > cleaned up, the GC will call the Finalizer. After calling the > finalizer, it will place the object for deletion. By calling suppress > finalize, you skip the finalize step and move to the deletion step. > > 2. Let me clarify by saying that I did not mean setting a local VARIABLE > to null. What I meant was cleaning up class level OBJECTS that have > been created by calling the dispose method and/or setting them to Null. > Of course, you are proving my point in that there are a lot of > programmers that are not willing to clean up resources and leave that to > the Garbage Collector, but it is ALWAYS a good idea and good programming > practice to clean up resources that you use. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Richard > Blewett > Sent: Thursday, September 06, 2007 11:45 AM > To: 'Discussion of advanced .NET topics.' > Subject: RE: [ADVANCED-DOTNET] l immediately release any unneeded memory > > Inline > > > -----Original Message----- > > From: Discussion of advanced .NET topics. [mailto:ADVANCED- > > [EMAIL PROTECTED] On Behalf Of Russell Collins > > Sent: 06 September 2007 16:44 > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > Subject: Re: [ADVANCED-DOTNET] l immediately release any unneeded > > memory > > > > I think what everyone has said has been good. If a memory leak is > > suspected, I would go and make sure that you make sure several are > > done in your code. > > > > 1. As a general practice, I always implement the IDisposable > > interface and put whatever clean up routines in it even if I do not > > have any unmanaged code. If I do have unmanaged code, I place the > > clean up statements in here as well. One thing that I also do > > (although I am not completely recommending it) is call the > > GC.SuppressFinalize() statement in the Dispose method so that when the > > > garbage collector tries to clean up the object, it does not call the > > finalizer statement but simply releases the memory. It is a small > > performance boost. In essence what it is saying is that I have > > already done ALL of the clean up necessary for the object, there is no > > > need to call the finallizer of the object, go ahead and release the > > memory. > > Bit confused here - you don't need to call GC.SuppressFinalize unless > you explicitly have a finalizer. It does nothing positive and is simply > overhead (IIRC correctly it will reset a bit that isn't set and try to > remove the object from a collection it isn't in) > > > > > 2. When coding, I ALWAYS call the Dispose methods of objects and/or > > set the object to null (or nothing in VB). Some people say that it > > isn't necessary to do all that because in a managed environment like > > .NET, the Garbage Collector does all of that for you. I think it is > > good programming practice to ALWAYS clean up your resources when you > > are completed with them. > > Setting a reference to null of a local variable does absolutely nothing > in a release build - the JIT compiler keeps stats of where the last use > of a local variable is and makes this info available to the GC so it > will collect at the earliest opportunity. > > However, setting a *member* variable to null in *some* circumstances may > be beneficial. For example if you are about to assign a new object to > the variable that is currently pointing to a large object or object > graph, and that assignment may take some time, then setting the > reference to null before the reassignment may allow the GC to collect > the object graph during the process of reassigning. > > Setting a static to null when you're finished with it is very important > as the GC will never collect the object(s) otherwise. > > So if you are trying to maintain a coding standard I don;t think there > is necessarily a big issue with always setting a variable to null when > you're finished with it as long as you understand how it may or may not > benefit your code. > > > > > Following these techniques, I do not get memory leaks. > > > > I assume you always unbind event handlers when you're finished as this > is a common cause of memory leaks too > > Regards > > Richard Blewett - DevelopMentor > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Tracy > > Ding > > Sent: Wednesday, September 05, 2007 12:17 PM > > To: Discussion of advanced .NET topics. > > Subject: RE: [ADVANCED-DOTNET] l immediately release any unneeded > > memory > > > > Q: Why do you want to do it yourself? > > > > A: One customer noticed service process had a large number of pages in > > > use and worried about a memory leak. > > > > > > Sincerely, > > > > Tracy Ding > > > > > > -----Original Message----- > > From: Discussion of advanced .NET topics. > > [mailto:[EMAIL PROTECTED] On Behalf Of Patrick > > Steele > > Sent: Wednesday, September 05, 2007 9:40 AM > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > Subject: Re: [ADVANCED-DOTNET] l immediately release any unneeded > > memory > > > > No. The garbage collector handles that for you. If you're utilizing > > unmanaged resources (files handles, windows handles, etc...), > > implement the IDisposable interface to make sure you release the > resources. > > > > Why do you want to do it yourself? > > > > --- > > Patrick Steele > > http://weblogs.asp.net/psteele > > > > > > -----Original Message----- > > From: Discussion of advanced .NET topics. > > [mailto:[EMAIL PROTECTED] On Behalf Of Tracy Ding > > Sent: Wednesday, September 05, 2007 12:35 PM > > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > > Subject: [ADVANCED-DOTNET] l immediately release any unneeded memory > > > > > > Is there some sort of .NET call that will immediately release any > > unneeded memory for service process? > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > > > =================================== > > This list is hosted by DevelopMentor(r) http://www.develop.com > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > > > =================================== > > This list is hosted by DevelopMentor. http://www.develop.com > > > > View archives and manage your subscription(s) at > > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com > -- Studying for the Turing test =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
