I received quite a bit of feedback regarding my Join extension to IEnumerable that generates a comma separated list.  The purpose was to emulate string.Join(), but to add more flexibility as to what is "joined".

I took some time aside to investigate some of the suggestions and alternatives to my implementation.  I should note, that I would not normally do this.  I try to avoid premature optimization.  However, there are certain practices that can be learned that improve performance in general (like using a StringBuilder).  With these in your toolbelt, you can build better performing applications the first time, and at little or no cost.  It takes no more effort to use a StringBuilder than to concatenate strings in a loop (at least once you become familiar with StringBuilder).  Regardless, the intent of this post is not to try to sell you on StringBuilder.

Consider the fact that many optimizations involve tricks or algorithms that could make the intent of the method less obvious.  Unless you really need that optimization, are you really willing to pay the price?  Most of us do not work on applications that require lightning fast code.  In my career, the only times that I have had to address performance in my C# code was when I was working with bulk import and export of data.  In those cases, I was dealing with hundreds of thousands if not millions of iterations of my code.  In this case, a millisecond here or there can make a big difference.  On the other hand, saving a couple of milliseconds to pull up an ASP.Net page is hardly worth the effort.

The bottom line is, your customers will feel the effects of broken code before they recognize a couple of milliseconds added to their page load times.  In other words, don't sacrifice readability and maintainability for run-time optimization (unless you absolutely have to - even then, get a second opinion).

posted on Wednesday, July 9, 2008 3:12 PM
Filed Under [ Agile .Net Design Productivity ]


No comments posted yet.

Post A Comment