The new 'fread()' can still lose ...

[James A. Woods]

#  No hinge nor loop to hang a doubt on. -- Shakespeare, Othello, Act III.
#  On horror's head horrors accumulate. -- Ibid.
__________

... to getc() for very small buffers, since some machines (e.g. VAX
11/750's) execute function calls [memcpy()/bcopy()] slower than small loops.

     The new version was designed to win on medium-to-large buffers
NOT because of better buffering (it's hard to do better than Ritchie's
stdio.h macros), but because the inherently "unrolled" nature of
a single machine instruction block character move eventually swamps
the getc() loop termination tests.

     Yet for small buffer size on I/O-intensive jobs [like compress(1)],
substitution of a tight getc() loop for fread() can still do better than
wading through a register/stack save/restore sequence (albeit hidden to most
users) for the TWO function calls (and a multiply!, at least on SVR2)
implicit when using the "modernized" fread().

     This is all moot on RISCs and 3B chips, of course, as well as the
archetypal gallium arsenide Cray 3, rigged to execute infinite loops in
a matter of seconds.

     -- James A. Woods   {hplabs,ihnp4}!ames!jaw   (or, jaw at riacs)