I think this is a book that should have been read by the majority of serious C++ programmers.
The subtitle to this book is 'Performance Programming Techniques' which well illustrates the authors' emphasis if you understand 'performance' to mean 'speed of execution' rather than 'code size.' Experienced C programmers can look at a chunk of C and make a pretty good guess as to how many machine instructions will be required.
This is difficult if not impossible in C++. One result is that C++ has got a reputation for producing slow, fat code. The problem is not implicit in the language but is the result of using inappropriate programming styles (coupled with compilers that are not yet very good at optimising C++, for example think about what happens when you dynamically bind a function inside a loop. We can realise that it should be possible to do the binding once, but most compilers will indirect through the virtual function table on every pass.)
What Bulka and Mayhew do in this book is to lead you through various examples highlighting the ways in which things can go wrong, sometimes with horrific costs in execution speed. It is not enough to show how things can go wrong, you also need to know how to program so that the compiler will have a good chance of avoiding the problem. The authors know this and show you their answers. Let me give one small example. C programmers declare variables early as a matter of habit. C++ has long argued that this is a poor idea because variables should not be declared until you are ready to initialise them. I must confess that I had never considered any more than this. Bulka&Mayhew point out that there is another important consideration, you should not declare a variable with a constructor until you know it will be used. A constructor, particularly one that uses dynamic resources, places a performance overhead that should only be paid if required. This is another version of 'do not pay for what you do not use'.
If performance really is never going to be important in your coding then you do not need to read this book. However if it might matter sometime then reading this book and modifying your coding style appropriately will probably mean that you will never even notice that your code always runs fast enough.
I think this is a book that should have been read by the majority of serious C++ programmers. By the way you will have a chance to listen to the lead author at the Spring JaCC where he is participating in both the C++ and Java tracks.