From: "Tom Payne" <twp20 AT cam DOT ac DOT uk>
Newsgroups: comp.os.msdos.djgpp,rec.games.programmer
Subject: Re: Any tips on optimizing C code?
Date: Sat, 17 May 1997 01:32:03 +0100
Organization: Cambridge University
Lines: 30
Message-ID: <5liuge$3e4@lyra.csx.cam.ac.uk>
References: <33775c59 DOT 19219875 AT news DOT cis DOT yale DOT edu> <5la59v$11b AT news DOT webspan DOT net>
NNTP-Posting-Host: goa.clare.cam.ac.uk
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

quark(particle) wrote in article <5la59v$11b AT news DOT webspan DOT net>...

>try to find a better way to do something... look for the algorithmic
>approach... most things.. (people don't realize) can be done
>with no divisions and no mults, and no shifts, and no floting
>point math... (I wrote a poligon fill without any of this stuff.)

I think this is absolutely the most important aspect of making your program
run as fast as possible. Quick sort is (almost) always faster than bubble
sort, no matter how well coded your bubble sort routine is. id's games
don't rely on hardware accelerated graphics or super-fast rendering: they
cleverly pre-calculate as much as possible beforehand and then use some
pretty cunning algorithms to do as little work as possible during the
game.

Squeezing maximum performance from your existing code is very much the last
stage of any project. Of course, given that you'll have to do it sometime,
it's important to know how to do it!

Be warned, however that compilers are fickle things and you'll find that
many C rewriting optimisations (like using i++ instead of i=i+1) depend on
the compiler your using. You'll find yourself targeting a particular
compiler for a particular processor: that's not very efficient if you want
to maintain a portable codebase.

(my $0.02 worth)

Tom Payne