Why not fast

From C

$Id: why_not_fast.txt,v 1.5 2009/02/19 21:28:54 db Exp db $

Premature optimisation is the root of all evil. (attributed to Hoare)

There are really good articles on the deadly newbie (and not so newbie) disease of premature optimisation. (Have a look on the web) I'll sum up the disease here and why it is a disease.

There are many symptoms of premature optimisation. These take (mostly) the following forms.

1) asm will speed up my code, so I need to redo my code to use asm. 2) function calls are expensive, so I will write big large functions 3) macros will make my code faster so I need to use macros. 4) gotos will make my code faster 5) threading will make my code faster, or I have a multicore processor so running threads will make my code run faster.

The key thing to always remember is optimisation should only be done after you have determined where the bottlenecks are. This is the error that programmers of all levels make over and over again; It makes no sense at all to speed up something to run in 5us instead of 10us (100% speed up!) if that piece of code is only run once in the entire lifetime of the program. The other key thing people forget over and over is the structure and algorithms will affect the speed of your program more than any other one thing. If you are using a bubble sort to sort huge datafiles, you can waste a lot of time looking for faster compilers, macro tricks, faster CPU or you can speed up the code amazingly by simply using a modern sort. This also applies to any algorithm you use, look at the literature; perhaps a new algorithm has been recently invented that is applicable to your problem set.

Now to cover the symptoms and why they are wrong.

1) asm will speed up my code, so I need to redo my code to use asm.

Redoing entire programs in asm takes a long time, it can still pay off for small chunks of code on some architectures; But again only after you have done your bencharking to isolate it down to these chunks. This is becoming less and less true with modern architectures. Can you do a better job of slot timing on a modern processor than a modern compiler? Unlikely.

2) function calls are expensive, so I will write big large functions

This may have been true of the VAX 11, but it is not true for a modern processor. If you do this, you introduce two problems. You now add the complexity of maintenance and perhaps made it buggier by hiding a bug. It's not worth it with a modern processor.

3) macros will make my code faster so I need to use macros.

I have covered this in why_not_macros, however the short and sweet summary is, you can actually make code slower if you blow up a cache line.

4) gotos will make my code faster

It is true C is bad at error exits, however, a modern compiler can do a much better job when it does not have goto's from the user to contend with. Prudence in gotos is suggested instead.

5) threading will make my code faster, or I have a multicore processor so running threads will make my code run faster.

  See Why_not_threads

--Dianora 21:04, 20 February 2009 (UTC)