-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|532|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
SoCoder -> Article Home -> Presentation and Organisation


 
HoboBen
Created : 16 May 2008
Edited : 16 May 2008

The Best Optimizer is between Your Ears

Are you writing fast slow code?

I wrote a function that loaded a nodemap from a file for the purposes of A.I. pathfinding, and it took a whole 19,000 milliseconds (19 *seconds*!!!) to run. With a fair bit of work, I managed to get it down to 8,000 milliseconds. Then optimising further, I shaved off another 600 milliseconds. I kept hacking away, and managed to get rid of another 100 milliseconds.

And I knew that was completely unacceptable. What I really had was fast slow code.

I took a whole new approach to the thing, and I got it under 85 milliseconds. It goes to show that if you have some code which is so terribly slow that you're forced to optimise, speeding up the slow code won't make a difference - the over-all design of the code is much more important.

Theoretically now I could shave a few extra milliseconds off my 85, but I think nothing demonstrates the case for design-before-optimisation better than my 223:1 improvement ratio!

There's an excellent 16 page PDF on the subject, which I really recommend, even if you don't read the source code:
The Best Optimizer is between Your Ears (4.3 MB, PDF)

 

Comments


Saturday, 17 May 2008, 00:27
JL235
I completely agree, 100%. It's all about the algorithm rather then how the algorithm is implemented. That has an effect too, but it's something you can work on later once you have a good algorithm worked out. Profiling your code is also important to find out which sections in your code are taking up the most amount of time.

A few months ago someone at Uni said that some collision detection code I had suggested was terribly slow. So I profiled my code and then pointed out that in total all the collision detection calls used about 0.1% of the programs total CPU time. So optimising it was really pointless.
Saturday, 17 May 2008, 04:05
Agent
That chapter was originally from Zen of Code Optimization
Good stuff, albeit a bit dated nowadays. But the Zen Timer still comes in handy
Saturday, 17 May 2008, 05:45
HoboBen
I found it in the Graphics Programming Black Book, by the same author which is a compilation of his writings on assembly language and graphics programming. You can download those PDFs for free, which is nice