The point I’d like to make is that the whole “PROFILE INLINE FUNCTIONS” thing is a bit back to front. The profiling should be done before the inline keyword is ever used. The ability to profile the function when it’s not inlined is just one of the good reasons not to inline until near the end, or at least not aggresively inline until then.

“Avoid Allocations” – C++ allows you to override the new/delete operators at the global or class level. As long as joe-programmer uses new/delete instead of malloc/free, he can later use that tuned pool allocator.

“AVOID ITERATIONS” – this seems like a local operation if the abstractions are configured correctly. If the system uses an subject/observer for whenever an object is added/removed, then the list of specific objects can be updated locally instead of globally.

“PROFILE INLINE FUNCTIONS” – This is absolutely supposed to be a late optimization. First get the algo correct and unit-tested, then profile and optimize. I guess the best approach is to build and then optimize, build optimize, etc…

“AVOID ALIASING PROBLEMS” – this is only matters inside inner loops so is a local optimization…

Each topic, reading the first sentence, I was thinking, “but what about…”, or “Yeah, like situation x…”, and the next sentence addrssed _exactly_ that.

Two examples, the section on allocation, I was thinking of particles, and a custom allocator, next sentence, about particles, and a custom allocator.

And about iterating over the list of objects, I was thinking “targetable objects, and a target list…”, next sentence: targetable objects and a target list.

It’s a good writer who can write in such a way!

The examples were just from my personal experience, and were mostly based on programing on the Sony Playstation 2. All were things that gave a good performance boost, and that I either did early, of wish I had.

Calling memory pools a premature optimization because they hide memory leaks seems a bit off. You can (and should) add debugging code to find leaks in whatever allocator you choose. It’s just as possible to introduce a memory leak bug at the end of a project as it is at the start.

I do agree with you though about the abstraction of reasonably high-level functions like “GetTargetableObjects”. Appropriate abstraction can help isolate potential bottlenecks. You do have to exercise caution, obviously, that abstracting excessively does not in itself introduce performance problems.

On your last point, you are basically talking about rapid prototyping. I’ve no problem with that, but calling something a “mature optimization” does not necessarily mean it has to be in there from day 1. Rather it means you don’t leave it too late. “Too late” can vary, based on the nature of the optimization, your code, and the project.

Take for example the “avoid iterations” tip. Avoiding unnecesary iterations is indeed a good idea. The example, though, shows why that kind of optimisation may not be good. The solution of using a list sounds like a good one, but what effect does it have on the rest of the system, when it comes to managing the objects, and is it really necessary, when other parts of the system might include space subdivision or proximity maps which would allow fast retrieval of objects? You might end up with a list solution, which not only took longer to code and was harder to debug, but made some parts of the system know about other parts they didn’t need to know about before, and eventually got thrown out because it’s still a slow and naive solution (still requires iteration to find nearby objects).

The point is, optimisation needs to be done with a global view. Potential performance problems can either be abstracted out — it’s pretty easy to create a “GetTargetableObjects” function that will be easy to change, as long as you find the right place for it — or have a generic solution implemented, one that’d be useful for all the various subsystems, with view of their requirements.

Another example of premature optimisation is memory pools. Sure, they will be faster than allocations and deallocations, but it’s also harder to find memory leaks when using them, since nothing is really released. Abstraction may help here, too, allowing allocations and pooling to be switched transparently.

So know and consider that iterations are slow, that RTTI may (in some cases) be an issue, and that allocations are slow. Then think of a way to write your code so that you could start with them and implement them out later. This way you’ll get a first playable (though slow) version more quickly, be able to squash high level bugs more easily, and when the time comes that the design of the game changes completely (as a result of that playable version) or your engine is switched, at least you didn’t write tons of ad-hoc code that’s no longer useful, or, worse, that you feel you must keep because you’ve worked on it so long, even though doing a code redesign to match the new game design would have been good.

But I think there is still some applicability to “other” applications. While it’s true computers will keep getting faster, you still have to make an impression with your product in the CURRENT market. If you don’t sell enough now, it’s not going to be helpful that your product runs lickity-split in three years.

The broader point here is that some optimizations are essentially either architecture optimizations, or are low-level, yet pervasive, and hence should be done early in the project. A stitch in time saves nine.

“Premature optimization is evil” is a tautology – if it’s premature, then you are doing it too early. The skill is to know what optimizations (and just general efficiency consideration) are worth doing.

The rest of the programmers in the industry work on projects that, if successful, have lifespans of decades. They have different values than game development projects. Wise investments today pay off dividends years, if not decades from now. Investing in coding clarity, bug tracking, revision control, unit testing, portability, regression testing, security hardening, etc. are all investments that appreciate in value with the progression of the project. Optimization, on the other hand, depreciates rapidly because of Moore’s law: every dollar of programmer time spent today optimizing code is worth half as much in 18 months, and incurs even higher recurring costs in the long-term because everyone else who touches it has to scratch their head and figure out what’s going on.

In non-game programming projects, really fast code can give you a competitive oomph! in the marketplace, but this needs to be carefully balanced against the risks. Will all of this hand-tuned C code matter in 10 years when the processor it runs on will be 50+ times faster?