Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: Spellweaver <spelwevr@mail.utexas.edu>
Newsgroups: scee.yaroze.freetalk.english
Subject: Re: Speed Optimisation
Date: Wed, 25 Feb 1998 17:01:10 -0600
Organization: The Implementor
Lines: 30
Message-ID: <34F4A2B6.2A5B@mail.utexas.edu>
References: <34F1D481.5FFF@mdx.ac.uk> <34F22032.A62E0C6C@netmagic.net>
Reply-To: spelwevr@mail.utexas.edu
NNTP-Posting-Host: tiphares.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.02 (WinNT; I)

Quoth Elliott Lee:
   [ ... ]
   > Something commonly overlooked is pointer dereferencing in things
   > like arrays.  If you're going to be doing lots of testing, it's
   > usually best to store the values into temporary variables.
   [ ... ]

Another good reason in favor of keeping a local copy of dereferenced
data:  Whenever you perform a function call, the compiler must
assume upon return that all dereferenced data has changed.  For
example:

void foo ( INFO * bar )
{
int a, b;
bar->baz = 3;
a = bar->baz; // Compiler should know that this is 3
anything ();
b = bar->baz; // Compiler must dereference bar here since
// ...        // anything() could have changed *bar
}

In fact, if the compiler is being particularly picky, it will
assume that all dereferenced data has changed after every write
to any dereferenced location.  It may even assume that all data
everywhere has changed, since technically that pointer could have
been pointing anywhere.  This may be a trivial effect in many
cases, but in a function with many pointers, particularly with
interspersed function calls, the compiler's attempts at
optimization can be defeated.