tmh said:
"Always use the int data type instead of char or short wherever
possible. int is always the native type for the machine."
"Always" is such a strong word. In some cases using short or char
(used as an integer) can actually create more efficient code because
they consume less memory. This might make a difference eg. with large
arrays, if the values fit well inside the short or char type value range.
Consuming less memory (especially with large arrays) is often
beneficial all in itself, but in many cases it's also beneficial because
it helps lessening cache misses (because more values fit into the same
amount of cache).
What ultimately is faster depends a lot on the program, and must be
measured explicitly.
"Make Local Functions Static"
I don't understand what this has to do with optimization. Anyways, the
C++ way of creating a local function is to put it inside a nameless
namespace. Making it static is the C way.
"Addition is faster than multiplication and multiplication is faster
than division. Factor out expensive operations whereever possible."
Addition might be faster than multiplication, or it might not. It
depends on the architecture, especially when talking about floating
point arithmetic.
There always becomes a point where "opening" a multiplication into
additions becomes slower than the original multiplication.
"Always try to pass classes by reference rather than by value."
This depends on the class. If the size of the class is, for example,
the size of an int, and its copy constructor is trivial (ie. usually
compiler-generated), it might actually be faster to pass it by value
than by reference. Again, it depends on the case.
"Whereever possible, use nameless classes[...] because, in the first
case, the parameter and the class share memory."
Have you actually measured that it makes a difference?
"Always use initialization lists in constructors."
Again the "always" word. There are situations where it's not possible
to use the initialization list. And there are other situations where it
is possible to use it, but not recommended (for example if a data member
is initialized with the return value of a member function, which should
not be called until the class has been fully constructed, which happens
only after the initialization list).
"Leave variable declarations right until the point when they're
needed. Remember that when a variable is declared its constructor is
called. This is wasteful if the variable is not used in the current scope."
Sometimes it's precisely because of the constructor call that a
variable would be better declared earlier. For example if a
heavy-to-construct variable is used inside a loop, it might be better to
declare the variable outside the loop rather than inside it, even though
it's first used inside the loop.
(Compilers try to move variable declarations out of loops when they
can, but they often can't do it if they cannot know if the variable
might be modified inside the loop, eg. because a non-const function is
being called. In fact, even calling a const function is not a guarantee
that the variable is not modified, and may stop the compiler from being
able to move the variable out of the loop.)
"Where-ever possible, count down to zero rather than up to n."
If you need the values in increasing order, calculating "n-i" inside
the loop may well nullify any possible benefit from that "optimization".
Overall, this feels very much a micro-optimization which doesn't
likely bring any actual benefit to actual code.
(And an interesting question is if traversing an array backwards is as
fast as traversing it forwards...)
"Note also that ++i is faster than i++ when it appears in the third
part of the for loop statement."
With basic types there's probably no difference. I bet most compilers
will generate identical code from both.
With things like iterators it might make a difference (although I
wouldn't be surprised if compilers wouldn't recognize the idiom and
optimize it).
"Factor out jumps."
Have you actually measured that it makes a difference?
