Search in Book Reviews

For example, it is not only those working on embedded systems that need to watch code size. About twenty years ago I can remember working very hard to get a piece of code down to 256 bytes. That was critical because it affected the addressing mode that I could use. These days we can have similar constraints with cache sizes and page sizes. Page faults can be expensive and loops that exceed the cache size can seriously degrade performance. The problem is that such considerations are very hardware dependant and so most of us should not be worrying about them.

Speed is another element that needs de-emphasis in the minds of many programmers. Too much speed can sometimes be a problem. The speed at which my screen scrolls on my high-end machine is far too fast for ease of use when I am word-processing or doing desktop publishing. The programmers responsible for such products need to provide some mechanism so that the user can control the scroll speed. On the other hand those working on such things as film animation need every fraction of increased speed they can get.

This book gives fairly comprehensive coverage to most aspects of optimisation, but, unfortunately, is limited in two ways; the authors use pre-standard C++ (and rather too much C for my taste) and they also use assembler code - indicative of their main platform experience.

Those writing code for small, embedded systems might benefit from some aspects of this book but for many others the problem is what is not there. Both performance and code size can be counter-intuitive. Over the last couple of years I have seen some surprising results. For example both Scott Meyers (in a yet to be published book) and Andy Koenig (in a column in JOOP) report an unexpected dramatic increase in performance when replacing function pointers with function objects (factors of seven to ten).

Then there is the problem of how exception handling affects performance and footprint. Surprisingly, techniques exist (for compiler implementation) that mean that an executable with full exception handling can run faster, and with a smaller RAM footprint than alternatives, so long as no exception actually gets thrown (all the panoply for handling an actual exception is held in separate code/data pages that are not loaded unless an exception needs to be processed).

The authors of this book touch on a few aspects of templates that allow some optimisation, but they miss the major ones such as 'hoisting'. They also miss mentioning the significance of the guarantee that unused function members of a template will not be instantiated.

I think that the thoughtful expert reader would be able to mine this book for some useful ideas that they could add to their toolkit for use when necessary. However, I would not want to let this book near a programmer who lacked the self-discipline to avoid optimisation until some measurement highlighted a problem.

Sadly the wrong people will be motivated to read this book. Perhaps the first rule about learning about optimisation should be "Don't", and the second rule should be "Not yet." If you understand that, then this book will do you no harm and some of the ideas maybe new to you.