I did read the article. The code iterates over ten million records, as does the example in the bug you linked. GC triggers when you allocate too much memory. That's why not doing allocations works in the first place. You can trigger a GC by iterating a small collectiona lot of times, but if you're talking about doing anything with what you're iterating you're going to trigger a GC anyway.

The issue in the article is a consequence of using interfaces, or really inheritance more generally. There's no real mechanism for passing information about an unknown class that doesn't involve boxing and unboxing. It happens all over the framework, and has nothing at all to do with IDictionary. It's just the price you pay for flexibility. That's the lesson of the article, except it's lost because the author spends two thirds of it misusing Dictionaries and then doesn't actually understand the point.

If you have a critical codepath don't take an data structure you don't know the properties of. If you need to do random access would you let someone pass you a linked list?

This article says beware of IDictionary, except the problem doesn't have anything to do with IDictionary. It misses the reason why this happens and provides no real understanding of the actual cause. On top of that it does the usual insanity of trying to avoid garbage collection as a naive goal. Garbage collection in critical paths is potentially something worth avoiding, if you can, in some circumstances.

It's a shitty article that misses the point.