I was chatting to a colleague recently who although he was a very good programmer, did not have a computer science/maths background – this was fine until he wanted to use bubble sort on a large(ish) (100k) number of records and I had to explain to him about how algorithms that take n2 time are not your friend for big (or even little) n.
One of the most important decisions you can make when optimizing an application is the up-front choice of algorithm to use, performance tuning and optimization can make a difference but you are very lucky to achieve 2x-5x improvement, to be able to make 10x or 100x improvement in your application you need decent algorithm choice.
Here’s a little table I put together to help explain why you have to be careful and know the time/space performance of any algorithm you put in your applications.
|Items||const||ln n||log n||n||n2||n3||2n||3n||n!|
Now is this the approximate time/space growth you will get; how long your process will take will depend on the cost of each operation and to give you a guide, here’s now many units there are in one year.
So if you happen to pick O(n3) algorithm you are going to have to waiting between 16 minutes and around 35 years to solve for just a 1,000 items!
Notice also that as the notation power grows, even micro-second execution times (or expanding onto Cloud infrastructure) isn’t going to help too much.