| more blog archives

Optimization Woes


I think by now everyone's familiar with the phrase:

"Premature optimization is the root of all evil."

In my day-to-day job, I worry a lot about writing high-performance applications, especially in the way applications manage and retrieve data. There is a huge difference between designing your application to be optimized for a specific purpose and premature optimization. It's one thing to worry whether echo or print is faster (who cares, really?) - but it's another to design an application to tolerate some slowness in low-traffic parts but gaining ultra fast response time on the first access to the application. For example, viewing your photo album may take a while but seeing the homepage is pretty freakin' fast!

In a recent post, Sebastian Bergmann points out that you should not micro-optimize (in reference to a PHP micro-optimization tricks post by Alex Netkachov). I agree wholeheartedly. It's a nice list and definitely something to keep in mind, but it should be just a small component of your developer bag of tricks! Before you can optimize, you have to design well first. Proper design leads to potential for great optimization. And to design well, you have to really understand the problem you're trying to solve. Sebastian links to slides by Ilia Alshanetky from PHP Quebec 2009 on Common Optimization Mistakes. Ilia also points out that it's important to understand before you start fixing:

Solve the business case before optimizing the solution.

For PHP Advent, I wrote an article Optimize This!, which talks about how to optimize an existing application. The most important part to focus on is understand what the application is doing and then figuring out where you'll have most impact. Sure, you can use echo over print (or print over echo, once again, who cares?) to get that 0.0001% performance boost, but if you're doing 140 live SQL queries on your homepage, your application will still have 3 minute response time and with more users, the performance will continue to degrade until the application becomes unusable.

Modularizing code (aka "Object-Oriented Programming") makes it easy to focus on problem areas in an existing application. Designing well doesn't always mean designing for high performance. Instead, it means designing for flexibility and atomicity - you want to be able to easily change things without huge impact on the overall system. So before you go an optimize, take a step back and think about what your application is doing and what it's supposed to do. Go write on the white board - diagrams prove very useful in figuring out flows and functionality! Go chat in #phpc channel on - the PHP community will help (with a little bit of playful making fun of, but we'll help). Just don't go changing all your methods to static methods unless you're really sure it's the right thing to do!

Comments (4)

2009-03-13 09:31:15 Les said:

You can still modulise using Procedural Programming but I agree with the point your making - using OOP is the way to go for truly wonderfully decoupled code, etc. Beside, does any professional web developer *still* develop using Procedural methods today? Come on... ;)

2009-03-10 11:16:32 Matthew Purdon said:

Hey Maggie, I totally agree with your sentiments. I think the real issue with that quote is that some of its meaning has been lost by people shortening it. The original quote is thus: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." I feel very strongly about the fact that people make design decisions based on efficiency over ease of development. Sometimes I wonder if they stick to a more procedural way of developing because they don't actually grok OOP. It's hard to see the benefits of object simplicity until you actually try to write things that way. Statements such as "I don't want to create too many objects" or "I use static methods for performance" are what keeps PHP out of The Enterprise. It has little to do with PHP itself.

2009-03-10 10:22:27 tedder said:

It's amazing to see the difference in how optimization is dealt with in industry versus in academia. Yes, optimization is important, knowing how to find the slow points are important (see Amdahl), but just as important is knowing when NOT to optimize or when to throw hardware at a solution. A good example was when it would take 20 hours to run through a daily log or dataset at our previous company. Yes, if you could move that to 12 hours or 4 hours you would come ahead. However, if it took 3 minutes to run through a day's worth of data, it didn't really matter. Developer time is a cost; "spend" it where you need.

2009-03-10 11:02:19 Paul M. Jones said:

"Designing well doesn’t always mean designing for high performance. Instead, it means designing for flexibility and atomicity - you want to be able to easily change things without huge impact on the overall system." Preach the Word, sister.