No one would deny the need for optimisation, if their newest programming creation runs like a crippled tortoise. But with the speed of a PC these days, is it worth bothering when your program runs acceptably fast?

In our opinion you have to consider the evolution of the PC. We used to have a single task environment, where you only needed to worry about your own application running okay.

Today we are more likely to see a PC simultaneously burning a DVD, running a distributed computing project, whilst at the same time a user is actively word processing, browsing the web, and quite possibly listening to an MP3. In the meantime in another room in the house someone else is listening to another mp3 streamed over the network from that same PC, which is also running a web server!  

In this intensive environment, unoptimised programs grabbing 10x the CPU they actually need to, can make the difference between burning a DVD or creating a drinks coaster.

Is the situation typically as bad as 10x over utilisation?  Anyone appreciative of the fact that raw PC speed has increased 1000 fold, since the early days of microcomputers, can't fail to see a problem with where all that power has dissappeared. Whilst a lot has gone into a GUI interface and extra features. A lot has also dissappeared into bloated inefficient code.

We have been running a few benchmarks comparing C++ class librarys for common tasks, these are classes designed one would hope to be reasonably optimal, but our tests revealed speed differences exceeding 80x, between the best and the worst. Now we know for a fact that some of these tasks could actually be done even worse by programmers relying on raw PC speed to get the job done. Programs can easily be hundreds of times slower that they need to be.

What are the answers? Well we are not about to suggest a return to assembly language! But we are wary of the ever onward drift of code away from the coal face, is C# for example even less efficient than C++?

In practical terms though whilst C# may have more overheads than C++ which in turn is slower than C, these overhead tend to fade into insignificence compared with the problems of using poor algorithms. It is how programs, sort, search, map etc that causes the vast majority of speed issues, a well written C++ program compiled with an optimising compiler may still only be half as fast as an equivilent assembly language program, but a assembly language program using a set of poor algorithms may be 100x slower than a C++ program using decent algorithms.

In our resource section on marsjupiter we hope to document and benchmark some of the algorithms you should be using, and to compare them with some of the "off the shelf" solutions you should avoid at all costs.