[.NET] Generics Perfomance Myth (and Tony Northrup VS Wendy Sarret)

According to Microsoft, Generics are faster than casting (even in absence of boxing/unboxing).

Tony Northrup - co-author of MCTS 70-536: Application Development Foundation (which BTW totally sucks, a review will probably follow) - states in the same book the following:

I haven’t been able to reproduce the performance benefits of generics; however, according to Microsoft, generics are faster than using casting. In practice, casting proved to be several times faster than using a generic. However, you probably won’t notice performance differences in your applications. (My tests over 100,000 iterations took only a few seconds.) So you should still use generics because they are type-safe.

I haven't been able to reproduce such performance benefits myself (and I am, as a Certified .NET Butcher, way more reliable than MCTS books) - so I'd say the performance gain is "supposed" more than "significant", unless someone is able to prove it. Until that moment .NET Generic amazing performance will remain a myth.

If you know something more than me about this - please share.

P.S. BTW - isn't Tony Northrup real HOT (I'd rather date him over Wendy Sarret)?

Thinking in Generic

Hi Folks,
Can't wait to hear more about Generics and Templates fine-very-not-butchery feature of modern languages?
Well, sorry to disappoint you but you've got the wrong track (I'm not such expert of that, btw, raise their hand those who created their own class using generics in the last week).
I'm gonna talk instead of how people (even honest butchers like us) can try to be as generic as possible while designing their application.
I wanna introduce my personal thumb rule:
Don't make any assumption if noone will risk his goddamn neck without it.
It may sound like an easy one, but in my experience this is, in the 80% of bad designs I've seen, the main root cause.
Sometimes I've been asking around questions like:

• "Why is that field of a so specific type ?"
• "Why you DON'T need to have such information on your class?"
• "Why these two classes do not have a common ancestor?"
• "Why these properties do not belong to a super?"

Problem arises when the answer is: "I don't need that in my case" i.e., "I can assume this in my case".
Well, even a butcher like me could still ask you WHY?
OK, I've got it.
YOU think that you can make that assumption but, even if it's true (so far), why should you?
What is the catch? Saving manicure to your hands or 30 minutes from your work-clocking?
I've got it, you are saving those 30 minutes to beat Lou on Guitar Hero (yes I know you are a geek).
But, if you can't find any other reason to make those assumptions, you should just make to yourself (and to those who'll handle your design after you) a favour.
Don't make them.
And this is the reason why: there are very good chances in the air that you would be bitching yourself within a month (or that your colleagues will be bitching you) for that, believe me.
It's just an honest advice from a butcher, you don't think it's worthless right?
That's all for today, I've gotta finish writing some ugly (very butchery indeed) nested loops...