🚀 go-pugleaf

In article <20837@watdragon.waterloo.edu> ccplumb@lion.waterloo.edu (Colin Plumb) writes:
>>[read()] Assuming your MMU can do copy-on-write, why copy?
>
>Because the odds that the user's buffers are properly aligned are not very
>good.  If read() allocated a buffer and returned a pointer to that, they'd
>be pretty much the same call.

The odds are very high that if the user is pulling in large chunks of data,
either he's malloced the buffer or it's a static variable.  Either way, it's
no big trick, given a bit of cooperation from library and compiler, to
ensure that any large buffer is page-aligned.  Sure, once in a while you'll
have to copy; not often.

More generally, there is *NO REASON* why the worst-case code and the
typical-case code have to be one and the same.  Usually it is a massive
performance win to optimize the bejesus out of the typical case and let the
worst case just muddle along as best it can.  Once in a long while you run
into a real application which triggers the worst case, and has to be fixed
(usually in some trivial way) for acceptable performance.  For example,
read() clearly has to be able to handle reads into buffers at any byte
alignment.  Back when Unix ran mostly on the pdp11, very few people ever
realized what a colossal performance hit pdp11 Unix took if the buffer
was at an odd address.  I suspect it's fairly significant even on most
modern machines.  Nobody cares, because it's very rare for a program
to ever do that.  I found out about it because one of the early Boyer-Moore
egreps did odd-aligned reads, and was actually slower than old egrep on
the 11.  20 lines of code fixed it.
-- 
"The N in NFS stands for Not, |     Henry Spencer at U of Toronto Zoology
or Need, or perhaps Nightmare"| uunet!attcan!utzoo!henry henry@zoo.toronto.edu