Skip Navigation LinksHome > View Post

Premature Optimisation

I remember having a discussion with a former team member on the demerits of Premature Optimisation. At the time we were discussing an approach to a particular problem.

The problem required that we converted some XML from one format into another and I suggested we should use a good old fashioned XSL. He didn't like this idea because he felt a coded version using an XmlReader/Writer would perform faster.

And he'd be right. But I still favoured the XSL approach - why?

We both agreed that the XSL option would have been significantly quicker to code; we estimated one days work to write and integrate the XSL version versus two days for the XmlReader/Writer version.

Isn't the extra day worth the extra performance?

In my opinion, probably not. You'd be better using that extra day to profile your application and actually measure where the real performance bottlenecks are.

Nine times out of ten, it won't be in the code you were about to optimise. Measure first, then optimise the bottlenecks.

I want to be 100% clear here that I'm not saying that performance isn't important - far from it. This approach is all about making your application perform as fast as possible by actually targetting the areas that are slowing it down.

You won't be so worried about the relative cost of XSL vs XmlReaders & Writers when you find your app is slow because the current approach means you are frequently transferring the same 60MB of data from your database with every request :)
A couple of weeks back I made a couple of posts referring to Martin Fowler's book on Refactoring. His book also has a couple of pages dedicated to Refactoring and Performance, and this paragraph is particularly apt:

"The interesting thing about performance is that if you analyze most programs, you find that they waste most of their time in a small fraction of the code. If you optimise all the code equally, you end up with 90 percent of the optimizations wasted..."

Note: I have deliberately avoided entering into any discussion on the specifics of the XSL versus XmlReader/Writer approach. I'm sure that there are merits to both - I use it here, purely as a demonstrative example considering only the time to code and relative performance.

Tags: Other

 
Josh Post By Josh Twist
11:21 PM
20 Apr 2006

» Next Post: Time taken to render a page in ASP.NET
« Previous Post: Exceptions

Comments are closed for this post.

Posted by Eric D. Burdo @ 27 Jun 2006 11:22 AM
There is also the "optimization mindset". You write your code using the more optimized methods.

Such as (for VB.net) using AndAlso and OrElse to shortcircuit IF statements. Using StringBuilder instead of concatenating strings. Using the best variable type for the situation.

Most of these people would say "DUH! That's common sense". But if you look at a lot of code out there... this stuff isn't done. If you do these optimizations AS YOU WRITE your code, then you don't have to optimize them later. Or premature optimize them later... (as the case may be). :)

© 2005 - 2014 Josh Twist - All Rights Reserved.