The evils of premature optimisation Written on March 23, 2011, by danbrown.
It is always tempting to try and speed up the bit of code you just wrote. Sometimes it is tempting to try and speed up code you haven’t even started yet by over-thinking the algorithm.
Unless your codebase is functionally complete or the code is so slow and/or resource hungry that it stops things from working, it is too early to optimise it beyond what is absolutely necessary.
Get it done
Optimising takes time, sometimes significant amounts of it.
In the majority of situations it will be better to get 10 features complete and slow/inefficient, than a single feature running perfectly. Once everything works, go back and optimise things that actually need to be fast.
With Moa we recently added a new major feature that meant we had to re-index potentially thousands of images if somebody changed a gallery. It is easy to do but took 15 seconds for 400 images as it performed one query per image. We left it as it was and carried on to implement the rest of the feature in other files. Once it worked everywhere we went back and made it fast. We still didn’t do it the ideal way (we just turned on transactions for the duration of the re-index) although it now only takes a fraction of a second so it is fast enough.
Direction change
Until you have the whole system there to use, you don’t always know if you have the right approach or if what you have done will even be in the end product. Features get cut to make release dates or because they were great on paper but suck in reality. Better to throw away a few hours rough work than an optimised version that took days.
Sometimes (or often in some industries) the requirements change halfway through a project and you have to throw things out. Nobody likes deleting code but it is better than leaving it unused to rot. You can always get it back from version control later if you reverse course again.
Ideally you would have a design signed off and things won’t change. Easier for agencies and freelancers to stick to, hard for corporate programming in a non-IT field.
Not just code
Algorithms are not the only place that can benefit from optimisation or be hurt by doing it prematurely. It is common for game developers to use machines that are vastly more powerful than the target hardware. This is a relatively cheap way to get all the features in place and still have a playable game. Once that is done and the content creators can start to do their thing, the coders get to work on the optimisation to target real hardware.
It might be that the project needs to be assessed once it reaches a usable state to see if it is even worth continuing. You want that done as early as possible to avoid wasting time.
When the PC game Quake was being developed, id Software chose to write it on NeXTStep workstations so they could run the game, the editor and other tools side-by-side and with more CPU power (four processors) than a PC. This let the artists and designers get on with doing their jobs and testing real content in-game without the limitations of a PC at the time. At that point they were the most important people to need it running. A nice non-code early optimisation to boost productivity.
Optimisation can also apply to just about anything so this is a general life tip too! I spent hours one weekend working out a route to travel from Bangkok, Thailand down through Indonesia and Malaysia, ending up at Darwin in north-west Australia. A few days later we changed our plans and decided to go to Japan instead so I lost all that time due to premature optimisation… It was fun working it out and I hope to do the trip someday but I would have been in trouble if my time was accountable to bosses and/or clients.[1].
When is it OK?
There are times you do need to optimise early. If the inefficiency stops the system being useful at all then it is worth optimising at least partially to get it working well enough to get on with more features.
I had a project once where I could only use Microsoft Access and Visual Basic for Applications. It was a 300Mb dataset that our clients had exported from MS SQL Server with tables of over 200,000 rows saved in mdb format. Some of the search queries I wrote would take several minutes to run, not good enough for what we needed it for and it was only going to get more complicated in the future.
We were only going to get updated datasets a couple of times a year so I decided I would optimise it by precalculating a lot of the stuff that it had to work out each time. The precalculation took 8 hours to run, but then searches took under a second. Well worth doing and we left it at that. 3 years later I had to do some updates to the code so I optimised the precalc properly and it down to around 20 minutes.
Another example would be if the brute-force version of an algorithm would use more memory than you had in the computer. Going back to Quake again, id used a precalculated PVS (potentially visible set) to save the PC having to calculate what should be drawn from a given location. It used too much of memory though, “several” Mbytes. They RLE compressed it and got it down to about 20kb instead.
Conclusion
The main thing to take away is to make sure you are doing the right thing before you spend time making it perfect.
In general, fully optimise if -
- There are no more major features to add.
- You know the feature is staying.
- You know (using real measurements) that the feature is causing a problem by not being efficient.
- The increased efficiency is needed right now.
Do you know any other reasons to optimise early? Or maybe a tale of when it has bitten you in the ass to? Let us know below!
- [1] Off-topic side note. Don’t micro-manage your travel plans in advance! I do enough to know what there is to see in the region, how the travel infrastructure works and what is needed for border crossings in the way of visas, currency, etc. I’ve made this mistake before and nothing sucks as much as arriving somewhere amazing and knowing that you only have a few hours before your next bus or train. It can also be very tiring trying to fit too much in. Better to see one thing properly than two or three things on rushed visit. The other stuff will usually still be there later.so you have a good excuse to go back. ↩
Read more from the Coding, Misc category. If you would like to leave a comment, click here: Comment. or stay up to date with this post via RSS
Social Bookmark :
Technorati,
Digg,
de.licio.us,
Yahoo,
Blinkbits,
Blogmarks,
Google,
Magnolia.
Leave a Comment
If you would like to make a comment, please fill out the form below.