Understand the impact that garbage collection has both at runtime and how it impacts the design of your APIs. Learn about finalizers, the Dispose pattern, the using keyword, and other related constructs. Notes from CLR Lead Program Manager Brad Abrams... Slide 3: Check out the CLR Profiler (as well as great 3rd party profilers for .NET) to help you track down memory leaks... Slide 5: One important thing about those “unmanaged” resources is that the .NET Framework covers most of these for you, that is you don’t have to worry about HWnds and HDC as WinForms encapsulates most of them for you. Remember this class is really targeted at the folks building class libraries such as WinForms, ASP.NET, the BCL, or similar libraries... If you just consume libraries in your app you should not have to worry about this. Slide 6: I should point out that VB.NET supports the using statement in the 2005 release and C++ has even deeper support.
Slide 7: as an interesting note at the ECMA C# committee meeting, there has been some discussion of changing the name of the destructor to finalizer... I personally think that would be a great idea as these things are way different than C++’s destructor. Slide 8: This condition where an instance would die in gen1, but lives on to gen2 simply because it has a finalizer is known as midlife crisis. It is the source of lots of extra memory usage in apps. Slide 12: As I listen to this, it just hit me that there is a clear principle around who should call Dispose()... For framework authors, you should NOT assume Dispose() is called by your clients. But you should make a effort to call Dispose() in your implementations. Slide 13: One tweak I made to this recently was to make it explicit in the code that Dispose() can be called more than once:
|
.jpg)