Array indexing vs. pointers...

[T. William Wells]

In article <607 at ardent.UUCP> mec at ardent.UUCP (Michael Chastain) writes:
: Good grief.  Say NO to low-level performance tweaking.

Good grief.  Say NO to understanding the language well enough
that "low-level performance tweaking" is natural to the
programmer.  Grrr.  Note that the quotes here are because I
disagree that the programming practices being condemned
constitute "low-level performance tweaking".

: I prefer to use the most natural data representation I can think of.
: If something's an array, I don't dink around inside it with pointers.

This completely irrelevant: one man's "natural" is another's
perversion.  The claim that such is "natural" is only a statement
of a personal preference.  My own preference is to think in terms
of pointers exclusively; and I tend not to use array indexing.
Note that I do not advocate using pointers for this reason, I do
so for a completely different one, which I will state shortly.

: If you had to debug this code with a typical sdb-like debugger, which
: would you rather look at?   "iArg" or "argv"?  I find wild array
: references easier to deal with than wild pointer references:  less
: likely to occur, easier to debug/find when they do.  I find all of
: these properties more useful than the small and doubtful performance

But *I* don't.  Personal preferences aren't natural law.

: gain that I can get by *increasing the entropy* of my code and data.

This asserts that the use of pointers increases the disorder
(that is what entropy is about, after all) in one's code and
data; this is entirely a subjective judgement.

---

At one time, I spent a lot of my spare time improving other
people's code.  One of the things I discovered is that almost all
the code I was dealing with had better than 25% execution time
fat.  What I mean is that when I merely changed all of the code
to follow my coding practices (which are not anything special,
just obvious things that every coder ought to know), it got that
much better; I am not talking about mere tweaks, nor am I talking
about optimizing particular sections of code.  I am talking about
reading each line of code and making obvious changes (things like
using temporaries when needed, adding appropriate register
declarations, eliminating obviously unnecessary function calls,
etc.)

Supposing that the 90-10 rule actually applies (which experience
shows to be something of an exaggeration, and utterly irrelevant
to a lot of well written code), and I were to take the same code
and optimize that 10% as much as possible.  I might expect that
to double the speed of the 10%.  Now, how much faster would this
unrealistic example get?  45%.

Now, let us compare these: if the programmer had trained himself
to code my way, he could have written the program to be 25%
faster *with no additional effort*.  Or, he could have it 45%
better doing it the original way, after all the additional effort
to optimize that 10% (if we are being optimistic, that is).

If he were to spend that extra effort on the code that follows my
practices, the resultant code would be 59% faster.

The point of all this is that learning coding practices that
result in writing reasonably fast code, and applying them, can
result in code that is as good or better (when measured by
execution time) as code written to standards that ignore
execution speed which is then optimized as necessary.  And having
learned to do this, one does not have to spend extra effort to
make faster code, it comes "naturally".

What I am calling for is an understanding of what kind of coding
practices make for good code, and the inclusion of execution
speed in the definition of "good code".

---

Now, as I said, I will justify why *I* use pointers almost to the
exclusion of arrays.

Most of the code I write in which efficiency is a concern falls
into one of two categories: code that takes a long time to run,
but will be run on a particular kind of machine, and code that
takes a fairly short time to run, but will get run on damn near
every kind of machine that is capable of running it at all.

For the code that takes a long time to run, it happens that it
will be run on a more-or-less conventional architecture: this
means that pointer references are generally going to be faster
than indexing.

For the others, what happens is that the unconventional
architectures also run the programs very quickly: the execution
time does not matter for these.  However, for a certain class of
conventional processors, the execution time is of great
performance: if the code is not fast enough on an 8086 (or
equivalent), it just isn't useful.  For most of these slower
processors, indexing is much slower than using pointers.

Now, for the last case, the reason is compelling: I *must* use
pointers instead of indexing as the code will not be fast
enough.  And, at least for my code, the 90-10 rule is pure BS:
rarely does *any* subsystem (never mind particular functions) get
more than 20% of the execution time.

---

The long and short of the above is that neither indexes or
pointers are intrinsically better than the other; programming
being a utilitarian art, "better" depends on what you want to use
it for.  And in C, given the equivalence between indexing and
pointer arithmetic, there can be no abstract reason for
preferring one above the other.

---
Bill

You can still reach me at proxftl!bill
But I'd rather you send to proxftl!twwells!bill