I was reading a book (in the appendix) that lists several methods of performance tuning. Most of them only increase framerate by a little bit (but more so on older computers). It was somewhat interesting, so I thought I'd query the infinite knowledge of a.cc to see if there are more tricks that you use. ComputerScience++;

Here are some of the methods mentioned (I'll probably have to go back to the book later to make sure I list them correctly) in the book (summarized):

• Plus, minus operations are faster than multiplication which is faster than divide. Multiplication can be significantly faster than divide on some machines.

  
  

• Pointer Indirection. Every indirection causes a "cache miss" which is ultimately some degree of slow down. Unfortunately, there's usually nothing you can do about this, other make your code less OOP and/or readable to comply.

  
  

• Data Structures. Try to use the smallest data type that will work for your variables.

  
  

• (Obvious) Use malloc/free and/or new/delete sparingly. Keep it out of the main game loop(s).

There were others but I can't remember right now.

Yes, but readability makes for more maintainable code. Avoid pointer indirections only if you have found the particular piece of code to be a bottleneck; otherwise I'd prefer readability over a marginal or unnoticeable speed improvement.

This doesn't always hold true. Data sizes that are not multiples of the target architecture's word size (32 or 64 bits on anything >= 386) can cause misaligned data and make things slower instead of faster. Why else do you think most modern graphics cards use 32 bpp instead of 24?

Use memory pools if you have to.

Here's some more:

• If you need to pass anything larger than a pointer, pass by reference if you can.

• Play nice with your optimizer: Write short functions, use the "const" keyword wherever appropriate, avoid complicated statements, cast explicitly, use the proper constants for initializing variables (float f = 5.0f; is better than float f = 5;), use the register keyword in very tight spots, use the inline keyword where appropriate

• Optimize algorithms, not code. For example, it is far more efficient to reduce the number of collision tests than to tune the test itself.

• Avoid float <-> int typecasts as much as possible. These are expensive; on modern machines, float math is almost as fast as int math, so you should only cast when you absolutely have to (e.g. passing the result of a float calculation to a function that expects ints)

• Use a profiler. Both to see which parts are worth optimizing, and to see if your optimization is really an improvement (you'd be surprised).

• You cannot optimize ALL of your code; focus on the 10% that is responsible for 90% of the user experience.

• Prefer math over if / switch statements. Math is fast, but if statements need branch prediction to perform well.

Avoid linked lists if possible and your overall design allows

Most other things have already been said. Start by thinking correct design that uses proper algorithms. Avoiding to do stuff is better than doing the stuff faster. Before starting to make things faster profile to see if you are working on the right piece of code.

Callgrind can be quite nice tool when combined with KCachegrind UI. Unfortunately I think it only works under Linux and possibly BSD and OSX. Here is a nice screenshot of one of my old program profiling output:
http://hoho.bafsoft.net/callgraph1.png

If you really need to get close to metal you might want to learn using special libraries that allow reading performance monitoring counters. [url
http://icl.cs.utk.edu/papi/]PAPI[/url] is one such but it doesn't work that well under Windows and using it in general is quite painful. Once you get it working you can monitor all sorts of interesting stuff. Things like branch mispredictions, cache misses, clock cycles spent in FPU and integer units, amount of SIMD instructions, cycles spent waiting for recourses and lots of other things. My Core2 has over 500 events you can monitor.

So... "x *= 0.5;" is faster than "x /= 2.0;"?

[EDIT] Deleted stupid half baked thought.

i think what was meant was more along the lines of, avoid putting new and delete in for loops. which does make sense.

and yes, forget / as a math symbol. / is a mistyped slash and that's all. you got \ for strings and * for numbers and that's all you'll ever need.

But new and delete are tools, great tools. Saying 'use them less' makes no sense.

What would make more sense is saying "use a smart allocation scheme". But use new and delete all you want, no sense holding out. And they don't turn evil once their inside a loop, that just makes no sense at all.

So then we agree:)

Depends on the processor, most modern processors implement sin and cos as single instructions. But I think I understand your point.