The three rules of optimization

Some people think these rules are only for novice programmers, but I think they are valid even for those in the genius class. Some examples and metaphors are in order.

When do I optimize my code?

1. Don’t
2. Don’t yet
3. Profile before optimizing

OK, so it’s supposed to be funny and memorable, but that doesn’t make it any less true. This is closely related to the rule of “smallest testable case”. When writing something, start by giving it the fewest moving parts. That may mean you make something that performs terribly, takes up a gig of RAM, eats up a ton of disk space, wastes 7 out of your 8 precious CPU cores, saves way more state information than you’ll ever need and doesn’t clean up after itself nicely.

But what DOES it do? It should work. Make sure the thing can get from point A to point B without driving off the road. Do that before you make the car go faster or turn sharper or get good gas mileage.

When you try to optimize as you go, you get distracted by rabbits trails. It’s like an author who can’t get her story written because she keeps stopping to fix every word or phrase that Microsoft Word has underlined in red on her screen.

Interruptions are coming to sabotage your programming productivity in just 45 minutes time! Don’t have nothing to show at the end of the day because your were sprucing up the error messages that Main() spits back at the user if their optional command-line parameters are not in the right format. Do that part later! Go build something worth caring about first and then go back and put some care into it.

Building a game server that needs to support thousands of connections? Get the TCP stack working with one thread and one client before trying to parrallelize everything. Each day has enough trouble of it’s own.

Another big reason to wait to optimize is that the design might evolve and a part you built might need to change drastically. Don’t spend all of Tuesday optimizing your Postgres queries only to have the lead switch the back-end to MongoDB on Wednesday. That’s a whole day flushed down the toilet. Instead, knock out real features. Keep pushing optimization back. Heck, maybe you won’t need it after all, or not much of it anyway.

The final point is that when you finally go to optimize, don’t just start where you think there might be something worth cleaning up. Profile the CPU, profile the memory and find out what is ACTUALLY making the software run slow. You might think it’s that nasty database query inside of a loop but the profiler will tell you it’s actually taking forever to timeout reading some third-party config file you hadn’t considered. If you have an infinite amount to time to optimize, then sure, do everything. But if you are human and exist in three dimensions like the rest of us, then you probably only have an extra week to spruce things up. Make sure you pick the best stuff to tidy. Don’t be scrubbing the closet with a toothbrush when the dining room table is piled with dishes. Profile first.

Donald Knuth said that premature optimization is the root of all kinds of evil in programming. Take his advice and knock out your first draft end-to-end.

engineers-boat

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>