From: wivey AT ix DOT netcom DOT com (William H. Ivey)
Newsgroups: comp.os.msdos.djgpp,rec.games.programmer
Subject: Re: Any tips on optimizing C code?
Date: 15 May 1997 20:48:51 GMT
Organization: Netcom
Lines: 53
Message-ID: <5lfsrj$sh7@dfw-ixnews3.ix.netcom.com>
References: <33775c59 DOT 19219875 AT news DOT cis DOT yale DOT edu> <01bc5f6f$c3000be0$cf1afec3 AT robert> <337865D0 DOT FB8 AT cornell DOT edu> <33793055 DOT 19327180 AT news DOT cis DOT yale DOT edu>
NNTP-Posting-Host: aus-tx6-20.ix.netcom.com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

In <33793055 DOT 19327180 AT news DOT cis DOT yale DOT edu> quacci AT vera DOT com (jon) writes: 
>

>I program on a 486 at home, and test all of it on a pentium at work.
>
>If you mean straight multiplication and division, yes, the gap has
>been closed, more or less. But a trick like bit-shifting is still
>faster than regular division, integer or FP. And unfortunately, you
>can only do such tricks with integers.

Good point. One thing, though, I wouldn't worry about actually writing
the code using shifts; unless it's something complex, the compiler's
optimizer will probably convert it to shifts (or something even faster)
for you.

>[...]
>Oh, I've measured and measured. This is why I posted this, and I'll
>ask again- has somebody else done all the measuring already? Is there
>someplace I can know that using a case is faster than an if, or are
>static ints a plus in functions that are called a lot- stuff like
>that. 

re: Case vs. if
If your compiler's optimizer is worth anything, it will probably turn a
switch...case construct into if...else if's or a table lookup depending
on which seems best to it. On the other hand, if your tests are such
that they lend themselves to a binary tree structure, you will probably
see a gain if you design your tests to minimize the maximum path. (An
optimizer might do this with a switch...case, but I wouldn't count on
it until I saw it happen.) (I once optimized a routine that performed
at least 8 tests using this method; producing a routine that contained
three times as many ifs, but had a maximum path of 3.5 tests and an
average of about 2.5.)

Another argument for ifs over switch...case is when you can reduce your
tests to ranges of values or a predefined boolean array indexed by your
test case.

re: Global/static ints:
I've found them to be slower in some cases. One thing to watch out for
is the "reluctance" of many compilers to optimize these things - you
often have to tell it it's OK by way of a command line switch or
#pragma. (The reason is that the safe assumption for the compiler is
that these values may not be stable - that is, they might be changed by
something outside of the function while the function is processing
them.) BTW, try putting commonly used constants into stack variables
rather than putting them into inner loops; sometimes helps a lot.

Finally, since "for" loops were mentioned earlier in the thread, avoid
'em. Use do...while where ever possible, and count down to zero when
feasible. You can get the "pre-test" benefit of a while by wrapping an
if around your do...while if you need to. For loops just do not seem to
optimize well compared to the do...while.-Wm