Ran into a scenario this past week with the GC.
Take this example:
With method is more efficient?
At first glance you would say Method1 since it “cleans up” its variables. Lets say o was actually a SqlConnection. We would want to clean that up at the end of the scope right?
Maybe not, turns out the garbage collector in .NET is smarter than us. In Method2, we don’t reference o after we are done using. Since it isn’t ever used again the garbage collector will come along and clean it up for you before the method ends. Pretty slick right? Declare, use, forget… and I get the optimum effect for free. Back to o being a SqlConnection, since o “may, if resources are needed or the os has some free time”, the connection will get cleaned up quickly.
Now, for the rub…
I was a good little developer and made sure the cleanup of my RootDisposable cleaned up its ChildDisposable when it was cleaned up.
I was also a good developer in that I implemented the Disposal pattern where the Finalizer calls Dispose(false), which will cause my child object to get cleaned up then also.
Now, for the cherry on the sundae, I built my app in Release mode for my customers, deployed it, and it broke for them. WTF!? (At this point blame QA, they should have tested the Release version instead of the debug! :D)
Check out the the trunk\Samples\AggressiveGarbageCollection sample in my codeplex site coderjoe.codeplex.com for sample that you can use to play around with this. Just remember the code will only fail if you build it in Release mode :)
I snagged my GC collect code from example in GC.KeepAlive method in the msdn docs.