Efficient coding considered harmful?

[T. William Wells]

In article <273 at tijc02.UUCP> pjs269 at tijc02.UUCP (Paul Schmidt        ) writes:
:     When I was optimizing I found some horrendous
: "efficient coding" practices that were used that
: made the code either less managable, less efficient
: or both.
:
:     Take, for example, my favorite:
:
: some_function(a_variable)
: short a_variable;

Here you are just demonstrating my point: had the programmer been
trained to write efficient code, he'd have known that, in general,
one doesn't declare short arguments (or float or char, for that
matter).

I'll repeat myself: I am not advocating optimizing one's programs, I
am advocating learning the coding techniques which generally result
in efficient code and applying them consistently.

:     The coder (who was inexperienced in C) wanted
: to optimize the space needed to save the parameter
: passed to the function.  This actually may add to
: the memory and time to do conversion between short
: and int.

Actually, declaring the thing short would not have been likely to
save any stack space: the caller almost always has to push an int.
(Except in ANSI C when there is a prototype, or in the unusual case
that the compiler can do inter-function optimizations.)

:     The worst violation of coding for efficiency
: was done in assembler.  The person set a condition
: bit inside a subroutine.  After the return the bit
: was used in a conditional jump.  Of course, another
: programmer saw the subroutine and couldn't under-
: stand why there was an unneeded operation in the
: subroutine and removed it.

Sounds to me like a documentation error: that returned bit is part of
the interface and should have been documented as such. Thus the error
you use as an example of bad coding for efficiency's sake is nothing
of the sort.

:     The time spent coding a project is only about
: 10%.  The maintenance phase lasts around 50% of a
: project.  If the coders write the most readable
: code for the maintenance, the entire project cost
: can be reduced.

Here we get the same old argument, rehashed: "efficient code is
unreadable". It is not necessarily true.  And in many cases, the
claim of unreadability is merely a demonstration that the reader does
not make it a practice to read that kind of code, rather than a valid
claim that the code is inherently unreadable.

I'll go even further: while there is code that is both unreadable and
efficient, the unreadability is more likely a consequence of the
programmer's inability or unwillingness to express himself properly
than a consequence of the code being written efficiently.

I'll even go so far as to say that efficiency antagonists compound
this.  By setting up the false dichotomy of efficient vs. readable
code, they convince programmers that they can either write efficient
code or readable code, but not both.  This merely makes people who
believe in efficiency give up the attempt to make their efficient
code readable. And, of course, their code is unreadable.

My own code is both efficient and readable. The former I know because
of testing; the latter because of feedback from people who have paid
money for it. So, I know that one can have it both ways.

: This is for a program to compute prime numbers:
:
: [code omitted, except for one line:]
:     for (i = 2; i <= root(n); i++)
:
: It is interesting to see that the square root
: calculation takes this much time for a function
: and is not needed to calculate primes.  It was
: probably an "optimization" to make the search
: for primes quicker.

It is more interesting to note that the simple discipline of avoiding
computing a thing more than once would have been sufficient to get
rid of most of the calls. Had the for loop been written

	imax = root(n);
	for (i = 2; i <= imax; i++)

two benefits would have been had. First, no time would have been
wasted waiting for or optimizing the thing. And second, the next
person who read the code wouldn't have to figure out that root(n) is
a loop invariant. (Trivial in this case, but not so in something more
complicated.)

:     In conclusion, I would like to stress that
: readability for the maintenance phase should
: outweigh the importance of optimizing code as
: it is written.  Easy to read code is easier to
: maintain, and easier to optimize.

Well, you said it, but you utterly failed to demonstrate it.  All
that you have shown are examples of where bad programming leads to
unreadable code as well as inefficient code.

---
Bill
{uunet|novavax}!proxftl!twwells!bill