Again, this is a case where a profiler must be considered. As I already stated here, you should really not base optimizations only on your assumptions or on statements of other people. It's important how your specific application works for your specific compiler. The second thing is that the actual bottlenecks are often completely elsewhere, and before they're not fixed, small optimizations are worthless.
I do agree with this. Just adding an example of an experiment I did a few weeks ago. The optimisations also depends on the target hardware AND software. The target hardware may seem obvious (greate graphic card => can do lot of graphics effects, etc), but I noticed something weird with the software side (the OS) :
- when launched from Mac OS X, my program was spending 80% of it's execution time on rendering the graphics, and 20% on my computing stuff (physical simulation) (50 FPS)
- when launched from Ubuntu, my program was spending 50% of it's execution time on rendering, and 50% on the computing (don't remember the FPS)
- and when launched from Window, my programe was spending 20% of it's execution time on rendering, et 80% on the computing (30 FPS)
The tests were done on the same computer, mine. And I know where is the bottleneck on Windows, and Mac OS X, and I can tell they are not the same.
Just to say that.. do you own tests!