Re: ZSH performance regression in 5.8.1.2-test

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

> On 26 April 2022 at 08:01 Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Mon, Apr 25, 2022 at 2:27 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > Theoretically we can block-read with impunity in cases 1 and 2 (anyone
> > disagree?).  Testing for seek-ability would allow doing the "read too
> > much and back up" trick in case 3.  I don't immediately see any way to
> > avoid reading one byte at a time in case 4, does anyone have a
> > suggestion?
> 
> Try this?

So the supposition is if it's not a pipe, providing we can detect that, it
can be optimised to a block read an a seek.  That ought to work most of the
time; presumably the thing is to think of nasty edge cases where the test
isn't good enough.  You probably get away with it most of the time even there,
in practice.

Not sure how much difference it makes but to avoid additional system calls
we could cache the result, invalidating it when we open a new file.  (We
could even cache whether a seek unexpectedly failed, but that might be
getting too paranoid.)

pws