

Tips for Optimizing C/C++ Code - chorola
http://people.cs.clemson.edu/~dhouse/courses/405/papers/optimize.pdf

======
yoklov
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](http://www.agner.org/optimize/optimizing_cpp.pdf)).
Not for the faint of heart, certainly, but very worth keeping bookmarked.

------
flohofwoe
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.

