Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!samsung!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Execution time bottleneck: How
Message-ID: <1991Feb22.174516.22773@athena.mit.edu>
Date: 22 Feb 91 17:45:16 GMT
References: <492@tin.crc.ac.uk>
Sender: news@athena.mit.edu (News system)
Reply-To: scs@adam.mit.edu
Organization: Thermal Technologies, Inc.
Lines: 30

In article <492@tin.crc.ac.uk> dcurtis@crc.ac.uk (Dr. David Curtis) writes:
> Now what follows I'm less sure of. The main aim is to avoid calculating
> array offsets and just increment pointers instead. Can anyone say if 
> that kind of thing produces significant speed-ups?

Schade; this comes up one week too soon.  Here is a sneak preview
of revision 1.24 of the comp.lang.c frequently-asked questions
list, coming soon to a spool directory near you:

100. Are pointers really faster than arrays?  Do function calls really
     slow things down?

A:   The answers to these and many similar questions depend of course on
     the processor and compiler in use.  If you simply must know, you'll
     have to time test programs carefully.  (Often the differences are
     so slight that tens or hundreds of thousands of iterations are
     required even to see them.  Check the compiler's assembly language
     output to see if two purported alternatives aren't compiled
     identically.)

     It is "usually" faster to march through large arrays with pointers
     rather than array subscripts, but for some processors the reverse
     is true.

     Function calls, though obviously incrementally slower than in-line
     code, contribute so much to modularity and code clarity that there
     is rarely good reason to avoid them.

                                            Steve Summit
                                            scs@adam.mit.edu