Tuesday, October 21, 2008 11:58 AM
As developers, we've been asked to "rework" pieces of code/sql to optimize it. But have you ever questioned WHY? Still forced to optimize eh? Seems like you've been stung with Premature Optimization.
A long, long time ago I was working on an ASP project using dynamic SQL, a well respected senior developer came in to review our work. Within 30m he concluded the reason the app was performing so poorly was cause of the dynamically generated SQL. Ignoring the facts the app was sizzling the previous two months before and the REAL source of the problem was a change to the protocols being used to access the db (Named Pipes vs TCP/IP protocols).
Fast forward a number of years, and I was working on a JSP page which had already been rewritten before (I was rewriting it a second time) and my code was being reviewed and judged inefficient due to the number of queries to the db. Ignoring the fact the page was to be used by clients about, oh, once a week, we were behind schedule and needed to get done as much functionality as possible, AND we knew this page was going to get rewritten in the future anyways. But none-the-less, I was tasked with a redo. The page and sql were rewritten to make one call to the db. After that, the exact same page AND query were rewritten numerous more times (I lost count to be honest) AND the queries broken out again and again all in the name of optimizing. Can you say “death by a thousand cuts?”
What’s common between these stories? Premature optimization by supposedly senior developers who are so myopic they couldn't see the trade offs between getting the current task done and a blind optimization philosophy . There will be PLENTY of time to optimize in the future, that is of course IF the need arises! If the need doesn’t arise, then it’s not important and the optimization time saved for more important things!
I’m not saying there is no place for optimization, but maybe we should be “making it work, THEN making it work fast.” This is where "Continuous Improvement" is a great asset. You should be monitoring your pages and query performance. You’ll very quickly see which queries are your heavy hitters requiring optimizations (rewrite to use indexes, maybe even create them or use new ones?).
Having said all this, there is no reason to be silly and purposefully coding an Order(n) algorithm, but I’m assuming you’re not doing that to begin with.
Something else I've read that urks me, when people say "it executes much faster." Uh hello?! What proof do you have of that statement? Can you cite any benchmarks to prove your point? Oh and that don't depend on executing the string concatenation twenty thousand times?! Have YOU done any benchmarks? Why should I take your word that shaving 200 milliseconds is going to make/break an application? Unless you're building up a BOOK with millions of strings, appending strings is not the end of the world. I'l be the first to admit, I like using StringBuilder instead of appending a bunch of strings together, but now a days, when I'm reviewing some code and I see a few string concatentations, I'm not going to have any conniptions.
There are VERY smart people at Microsoft, Oracle, IBM, and Sun, they’ve done great jobs of optimizing the compilers and DBs you’re using. Sometimes if you’re seeing degradation in performance, it’s possible you’re being “too smart” and not taking advantage of all their smarts. If you read this last part and are thinking to yourself "that's just wrong", all I can ask is, do you REALLY think you're smarter than 10,000 developers from all over the world, some with master degrees and some just really smart musicians with creative minds?
These are a few things to consider the next time you think "hhhmmm we should optimize that." If you're doing it cause a customer is complaining or cause your QA people are saying a page takes too long, GREAT! Go for it! But if you're doing it cause you're in design phase, maybe it's it premature?