Call me crazy. I’m so swamped but just got bit by the curiousity bug and did some very silly perf tests on Beta1. A few months back, Krzysztof Cwalina posted some Design Guidelines for Generics. In it, the BCL team recommends using <nullable> for value types. At that time I was curious about the performance although he did say : “We will work to make these two important generic types as efficient as possible.“  (he was also referring to <EventHandler T>).

Testing against the March bits of Whidbey, HasValue was a LOT slower than just testing, say for an int32, if it is >0 . So I went back and played with this again with the beta. I started with 100 iterations. All tests returned 0 milliseconds! (I also tested a random object just for fun). I pushed the iterations to 1,000, then 10,000. Still 0 milliseconds for everything. Finally at 100,000 I saw a glimmer of difference but not in favor of HasValue. At 500,000, you can see (below) that both functions are finally sweating a little at a whole 2 , 3, 5 and 7 milliseconds – if you can call 3 milliseconds “sweating“. Pretty fast! However, the HasValue is still slower. In my little test case, of course, this is not earth shattering. But obviously in more complex scenarios, stuff like this does matter.

At this point, they are still working to make a real performance case for nullable and hasvalue (remember, this is all in VB where I am playing) and I’m sure they will.

Just for fun, I checked the performance in .Net 1.1. Now that is on a machine with 2GB of ram and 2.8 GHz processor speed. The Whidbey tests are on a machine that is 1.6 GHz with only 512MB of RAM. So, looking at the test of int>0; the whidbey performance compared to 1.1 is even more impressive than what I saw here. THe 1.1 is on the left. Beta1 is on the right.

God only knows why I just wasted all this time thinking about this itty bitty little thing. I certainly have bigger fish to fry this week.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!