A note for those not consumed by efficiency worries

[Herman Rubin]

In article <1084 at targon.UUCP>, ruud at targon.UUCP (Ruud Harmsen) writes:
> In article <1990Mar22.072712.10902 at diku.dk> jensting at skinfaxe.diku.dk (Jens Tingleff) writes:
> >
> >	MAKE THE THING WORK, THEN MAKE IT FAST.
> >
> True.  But only with one very important footnote:
> 
> While making the thing just work, do consider performance, and know where and
> how you might want to optimise later.
> If in the design of a programme or system you totally disregard all
> performance issues, you might have to rebuild large parts from scratch,
> and/or make the whole thing totally incomprehensible when optimisizing.
> 
> I've seen things like that happen, and I can tell you it's a tragic sight
> to watch.  A much better approach is to have the spots for optimization
> marked and planned, so it is easy to fulfill, will be really effective
> and does not violate the original design.

There are far too many algorithms which work, but cannot be speeded up
appreciably, while other algorithms are very much faster.  The choice of
the algorithm depends on what can be done in the hardware.

A good example is the frexp() function in 4.2BSD.  This was (ugh) coded in C
for the implementations I have seen in a straightforward manner.  By using
additional resources, it could have been speeded up in the (unfortunately
too common) bad cases, but only by using additional resources and running
slower in the better cases.  It worked, but could not be made fast.

However, a semi-portable machine-dependent algorithm, deliberately ignoring
typing, could be written which is in the ballpark of machine language 
algorithms.  Starting with these, one could make it fast.  But unless
the operations of pack and unpack are in the language, this cannot be
done otherwise.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)