Re: ZSH performance regression in 5.8.1.2-test

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2022-04-25 11:56:59 -0700, Bart Schaefer:
> On Mon, Apr 25, 2022 at 11:26 AM Jordan Patterson <jordanp@xxxxxxxxx> wrote:
> >
> > This recent fix has led to a performance regression in zsh: 49792:
> > Non-interative shell input is line buffered.
> 
> Hm.  If we use stdio for speed, we have memory management re-entrance
> issues that can lead to a crash.
> 
> If we use direct read of more than one character at a time, we can't
> enforce line buffering.
> 
> Is there a way we can detect the case where we need to line-buffer and
> avoid it otherwise?
[...]

Sorry if I'm beside the point as I don't know the context here,
but in cases where it's important that we don't read past the
newline character that delimits an input line (like for the read
builtin), some other shells, when the input is seekable do read by
blocks (instead of one byte at a time), and seek back to just
after the newline when they've read too much.

That explains why using "read" on regular files can be
significantly slower in zsh than in ksh/bash.

ksh93 goes even further (but that causes bugs, and I'm not
suggesting zsh goes there) in that the
second "read" on the same fd reuses information that was
retrieved from the previous read.

It also explains why ksh93 uses socketpair() instead of pipe()
for its pipes on Linux, as you can /peek/ at their contents
without consuming them. Again, that comes with its own set of
problems.

-- 
Stephane