In my previous article on Performance Requirements I argued that performance issues are requirements, and that this is not well understood in the software development community in general. In this article I’m going look at the performance tuning of existing code, argue that this is also poorly understood, and discuss the right way to go about it.

My friend Alan Griffiths related an experience of his from a few years ago. He was working on a desktop product written in C++. In this case the performance requirements of the software had been managed sensibly, in that performance criteria were understood. Alan was tasked with improving the performance of specific functionality by a factor of two.

How to go about this? Well, the functionality he was tasked with optimising used did quite a lot of searching and sorting of data. This had led to an implicit assumption (among some members of the development group) that this is where the improvements would be needed. However, the C++ development environment in use had a profiler, so Alan set about obtaining concrete information on where the problem really was – and the result was something of a surprise! Execution seemed to be spending a lot of time in string::operator== ! A quick look in the library source code quickly gave a clue: the operator== implementation simply called the C strcmp function. Alan decided that he had, at this point, obtained enough information to try something simple: he wrote a replacement operator== that first checked if the strings were of equal length, and simply returned false if they were not. This was enough to solve the problem! In fact, it delivered a factor of four improvement – twice as much as was deemed necessary – at no extra charge!

I have, many times throughout my career, seen programmers dive in and start speeding up code based on guesswork and unfounded assumptions – indeed, in my less experienced days I dare say I was guilty of this myself (just don’t tell anyone). This is a waste of time. Alan could easily have spent lots of time trying to optimise searching and sorting code, when this time would have been wasted. Unless you actually measure the performance of various parts of the code, you don’t know what is causing the code to under-perform. As illustrated above, this is true even if there are “obvious” candidates!

The moral of this story is a recurring theme: avoid guessing! Instead, gather concrete evidence of where the problem lies before making changes to the code.