Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Allright, allright, so I've taken the pledge, happy now?

The last 2 nights have been spent feeling guilty for the crimes that I've committed.  They were never really *big* crimes, more like indiscretions I'd say.  Anyway, reading the new article on Msdn titled Writing Faster Managed Code was a timely reminder about what is required to write quality code.

Basically, the author implores you to go to the trouble of "measuring" things as opposed to going with "gut feel".  That sounds fine, but, measuring things is not always as easy as you might think, so, if you're a NEWBIE like me and you're used to going with "gut feel" you'll probably need to go through another period of adjustment too.  Don't get me wrong, you're not being asked to measure every single operation within every single line of code, just to understand the cost implications of things such as: Object initialization, Data Type choice, Storage access times, and, other lower-level things such as being friendly to the GC process and boxing.  To steal a performance related quote from Jeffrey Friedl:

"I use these exact numbers not because the precision is important, but rather to be more concrete than words such as 'lots', 'few', 'many', 'better', 'not too much' and so forth.  I don't want to imply that {blah} is an exercise in counting tests or backtracks; I just want to acquaint you with the relative qualities of the samples."

So, now that I've said it:

"I promise I will not ship slow code. Speed is a feature I care about. Every day I will pay attention to the performance of my code. I will regularly and methodically measure its speed and size. I will learn, build, or buy the tools I need to do this. It's my responsibility."


...go ahead, you say it too!

2 Comments

  • I will never take that pledge. Speed isn't everything. In today's software, robustness, ease of use (by developers), simplicity and other things are as important as performance and most of the time more important. When speed is important, looking at tiny instructions will NEVER help you. Optimize the algorithm, not the instructions. Read my blog for an excellent example :)





    Using the profiler supplied I found a memleak in the IsDBNull function in the SqlDataReader. Haven't heard from MS yet. :)

  • Haha that's rediculous. No way

Comments have been disabled for this content.