There's some good and bad advice here.

Avoiding (or at least thinking about) branches, avoiding mallocs, and simplifying equations out by hand before you code them are all hugely worthwhile. Thinking about the memory usage access patterns of your program is a must if you work in realtime simulations. (Simplifying equations is enormously important, and I'm glad to see it mentioned because most people assume that the compiler can do it for them, which in most cases it cannot).

OTOH much of this advice won't make any difference other than making you code harder to read. Using local variables won't increase register pressure compared to not using a variable for that computation. Very few compilers will actually generate temporary objects for `Vec3 res = Vec3(a, b, c) + Vec3(d, e, f) + Vec3(h, i, j)`. As I understand it, using memset vs letting the compiler zero initialize an array of classes is unnecessary unless you compile with `-fno-strict-aliasing` or similar.

For small programs, rolling your own STL data structures isn't the worst advice, especially given that his target audience seems to be students (I work in gamedev, and I wouldn't want to work with someone who couldn't code up a STL-like templated vector, exception safety aside). Neither is avoiding templates (at least, before you can tell by looking what kind of code a complex template will expand to).

Anyway, for better, more thorough, and more actionable advice, there's always [Agner Fog's excellent guide to optimizing C++ programs](http://www.agner.org/optimize/optimizing_cpp.pdf). Not for the faint of heart, certainly, but very worth keeping bookmarked.

I think the list goes into too great detail, it feels like half of the points are taken care of by the compiler and may change with the used optimization switches or target CPU. For instance: "use shift instead of mul or div", I remember that this was an issue in the early 90's, but I think every modern compiler should be able to figure this out. Or the general advice to pass by-references instead of by-value, this actually backfired on the early Xbox SDK compilers which had SSE-style vector registers, and where it was better to explicitely pass those by-value, since then the compiler would put them into registers (later compiler version would figure this out by themselves, even if pass-by-ref was used).

In general, there's no way around inspecting the generated assembly code while trying out different optimizer switches and code tweaks, and running the code through a profiler.