Suppose there is the following code:
foreach (...)
{
List<int> localList = new List<int>(100);
// do stuff
localList = null;
}
From time to time, I am tempted to null references just as the procedure is about to exit (that is, return) or in this case, just as it is about to loop. Is there any benefit to doing so, even if a small one?
No. In fact, "nulling" local variables can, under some circumstances, prevent garbage collection. In normal operation, as soon as a variable is no longer reachable from any executing code, it becomes available for garbage collection. If, at the end of your method, you "null-out" the variable, you keep it "alive" until that moment, and actually delay it's availability for garbage collection.
Not if the declaration is within blocks like you have. Once it's out of scope the reference will be nullified automatically and GC'd.
There is no benefit to doing this for local variables. The CLR knows, by means of the JIT, exactly when a local variable is no longer used within a method and hence collectable.
Raymond Chen recently did a very in depth blog article on exactly when objects are collectible . It covers this scenario in detail and is worth the read
There is however a couple of exceptions to this rule. If the local variable in question is captured into a closure or an iterator then yes nulling out the variable has an effect. Namely because the local is no longer a local but instead is a field and has different GC semantics.
I wrote a long and exhaustive blog article answering this question.
To summarize, the general answer is "no; there is no benefit". However, there are a few special cases:
IDisposable.Dispose does not meet this test, and should not be encouraged].In conclusion: generally speaking, setting variables to null to help the garbage collector is not recommended. If it is deemed necessary, then an unusual condition exists and it should be carefully documented in the code.
If a class has a finalizer, any non-null object-reference fields will cause the referred-to objects to be held longer than they otherwise would. If the objects are known to be unnecessary even before the finalizer runs, clearing out the object-reference fields will allow the objects to be collected one "generation" sooner than they otherwise would be. That can be a big win.
If the lifetime (useful or not) of an object is expected to outlive the useful lifetime of an object to which it has a reference, needlessly holding a reference will prevent the latter object from being collected until the former is (i.e. the reference will force the latter object to be kept even after it has become useless). Clearing the reference will avoid that problem.
If a class written in vb.net has any "WithEvents variables", they should be cleared out (set them to nothing) any time the object holding them becomes useless. A class cannot be garbage-collected while it holds a reference to a live object in a "WithEvents variable". If e.g. an enumerator holds a "WithEvents" reference to an underlying collection (e.g. so it can receive events if/when the collection is changed) and its Dispose handler does not clear its reference to the underlying collection, the enumerator will be kept alive as long as the underlying collection is. If the collection is enumerated very many times, this could be a massive memory leak.
There is one important case where nulling has an effect, which is when you are using a debug build with some jit optimisations turned off. A lot of the funkier behaviour as to when objects are cleaned up can stop, to make debugging easier.
It's important, because it can lead to a false view of what is happening in the release build.