See this.

I love "The Premature Optimizer":

Never use String.IsNullOrEmpty! Didn't you know that there's a huge bug in the Framework that makes that function kill kittens if you call it on a multi-proc system with more than 4.5 gigs of RAM? Plus, it adds five microseconds of overhead as it accesses eax twice necessitating 4 extra clock cycles. Measure it? Should I have to, it's SO obvious that's inefficient!

When I write code, especially when alone, I imagine I am having a conversation with someone and trying to explain what I want the computer to do through code. It's like pair programming with an imaginary friend I call, "Future-Guy-That-Has-To-Maintain-This-Code." Not as good as real pair-programming, but whatever. 

When I read this, I remember thinking, "Crap! I've been saying String.IsNullOrEmpty is the bomb for a long time now, because it's so obvious and self-explanatory...now I am going to have to stop using it and explain why every freaking time! This sucks!" I recovered, but I think my imaginary pair-buddy that day must have been "The Premature Optimizer."

As to the labels/stereotypes thing: I think a better name for this would be "anti-pattern." These are all examples of people I _wouldn't_ want to work with, not personality types I hope the Visual Studio team wastes valuable time catering to, unless it's in the form of a cure or some kind of corrective treatment.


 
Saturday, July 28, 2007 8:14:52 AM (Pacific Standard Time, UTC-08:00)
I can attest to the fact that Mort doesn't know string.IsNullOrEmpty even exists. I've heard the same arguments against "" versus string.Empty. "" is often clearer, but slower.
Friday, August 10, 2007 9:39:24 AM (Pacific Standard Time, UTC-08:00)
string.IsNullOrEmpty is a serious bug. Sure, you can call it premature optimization... that is, until your application crashes at runtime because this bug bit you in the ass, but you were too arrogant to heed fair warning.

Now, if you want to lump Bill in with people you don't want to work with, then by all means do it because he didn't entirely explain the issue. The call to IsNullOrEmpty has to be the last call before the stack is popped to trigger the bug. Knowing this you should be able to decide where and when to manually use mystring==null || mystring==string.Empty instead of IsNullOrEmpty.

It isn't a performance issue in this case; it IS a serious bug. Now as for the "zomg performant!" arguments that our often spouted in ignorance: I totally agree with you. I don't want to work with them either.
Friday, August 10, 2007 4:36:24 PM (Pacific Standard Time, UTC-08:00)
Thanks for the clarification Jay! I would be honored to work with Bill, though. He experimented, wrote some code, found out something really important, and shared it with everyone. The premature optimizer would have been too busy optimizing code to write that post.
Comments are closed.