I wanted to create a follow-up post in my series on IEnumerables, iterators, and collections focusing on performance characteristics. When checking out the runtime performance and memory characteristics between these materialized collections and iterator benchmarks, I was very surprised! Check out this article for performance benchmark characteristics and some curious finds.
This article is not set out to try and persuade you, the reader, that either using an iterator or materialized collection will universally solve your problems. Both iterator and materialized collection usage can be used to solve the scenarios that we'll be looking at, but both will come with a different set of pros and cons that we can further explore. The purpose of this article is to highlight scenarios based on real world experiences where either an iterator or materialized collection was being misunderstood, misused, and ultimately leading to a pile of headaches. As you read this article, if you find yourself saying "Well, sure, but they should have..." you're probably right. The problem is fundamentally not the usage of an iterator or the materialized collection, but not understanding how to consume them effectively. So I hope that when…
Yield: A Little Background The yield keyword in C# is pretty cool. Being used within an iterator, yield lets a function return an item as well as control of execution to the caller and upon next iteration resume where it left off. Neat, right? MSDN documentation lists these limitations surrounding the use of the yield keyword: Unsafe blocks are not allowed. Parameters to the method, operator, or accessor cannot be ref or out. A yield return statement cannot be located anywhere inside a try-catch block. It can be located in a try block if the try block is followed by a finally block. A yield break statement may be located in a try block or a catch block but not a finally block. So what does this have to do with API specifications? A whole lot really, especially if you're dealing…
Background If you've poked through my previous postings, you'll probably notice that I love using events when I program. If I can find a reason to use an event, I probably will. I think they're a great tool that can really help you with designing your architectures, but there are certainly some common problems people run into when they use events. The one I want to address today has to do with memory leaks. That's right. I said it. Memory leaks in your .NET application. Just because it's a managed language doesn't mean your code can't be leaking memory! And now that I've got your attention, let's see how events might be causing some leakage in your application. (There is source that you can download and run. Check the summary section at the end!) Instance-Scope Event Handlers One of the…
