zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Bart Schaefer <schaefer@brasslantern.com>,
	Jordan Patterson <jordanp@gmail.com>,
	 Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: ZSH performance regression in 5.8.1.2-test
Date: Mon, 25 Apr 2022 14:27:54 -0700	[thread overview]
Message-ID: <CAH+w=7Yz-usT3nbbOW8o-awgZ_EKYVDaM_VVhyKYwaiOdxRzzw@mail.gmail.com> (raw)
In-Reply-To: <20220425192036.p6awbyro2a2lp7bq@chazelas.org>

On Mon, Apr 25, 2022 at 12:20 PM Stephane Chazelas
<stephane@chazelas.org> wrote:
>
> 2022-04-25 11:56:59 -0700, Bart Schaefer:
> > On Mon, Apr 25, 2022 at 11:26 AM Jordan Patterson <jordanp@gmail.com> wrote:
> > >
> > > This recent fix has led to a performance regression in zsh: 49792:
> > > Non-interative shell input is line buffered.

Jumping back to this for a moment:
> > > Summary
> > >  'prefix/5.8.1/bin/zsh -i -c exit' ran
> > >    1.16 ± 0.06 times faster than 'prefix/5.8/bin/zsh -i -c exit'
> > >    9.22 ± 0.27 times faster than 'prefix/5.8.1.2-test/bin/zsh -i -c exit'

I hadn't parsed closely before that 5.8.1 is faster than 5.8.  That
means avoiding stdio is faster if we don't have to do 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,

The context is shell command input, that is, any of
1) loading init files
2) source or . command
3) zsh < file
4) command | zsh

Have I missed any?

The bug from https://bugs.gentoo.org/839900 crops up in a special case
of 3 or 4 when the input runs a sub-command that itself wants to read
from stdin.  In that case the shell is supposed to have stopped
reading at a newline, leaving the rest of the original input available
to be consumed by the sub-command.

>[...] 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.

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?

It does not appear from some quick tests that lseek(SHIN, 0, SEEK_CUR)
is guaranteed to succeed in case 3 nor to fail with ESPIPE in case 4.
How to distinguish them?


  reply	other threads:[~2022-04-25 21:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-25 18:16 Jordan Patterson
2022-04-25 18:56 ` Bart Schaefer
2022-04-25 19:20   ` Stephane Chazelas
2022-04-25 21:27     ` Bart Schaefer [this message]
2022-04-26  7:01       ` Bart Schaefer
2022-04-26  8:31         ` Peter Stephenson
2022-04-27  0:33           ` Bart Schaefer
2022-04-27 14:11           ` Stephane Chazelas
2022-04-27 15:02             ` Bart Schaefer
2022-04-27 15:07               ` Peter Stephenson
2022-04-27 15:17                 ` Bart Schaefer
2022-04-26 14:31         ` Jun. T
2022-04-26 15:15           ` Peter Stephenson
2022-04-27  0:55             ` Bart Schaefer
2022-04-27  9:16               ` Jun T
2022-04-27  0:38           ` Bart Schaefer
2022-04-27  9:34             ` Peter Stephenson
2022-04-27 10:28               ` Jun T
2022-04-27 12:42                 ` Jun T
2022-04-27 13:58                 ` Jun T
2022-04-27 15:25                   ` Bart Schaefer
2022-04-27 16:18                     ` Jun. T
2022-04-27 19:54         ` Jordan Patterson
2022-04-28  9:53           ` Jun T
2022-04-28 14:56             ` Bart Schaefer
2022-04-28 18:51           ` Jun. T
2022-04-29  0:28             ` Bart Schaefer
2022-04-29  2:25               ` Jun. T
2022-04-26  1:08 ` Bart Schaefer
2022-04-26  3:03   ` Jordan Patterson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH+w=7Yz-usT3nbbOW8o-awgZ_EKYVDaM_VVhyKYwaiOdxRzzw@mail.gmail.com' \
    --to=schaefer@brasslantern.com \
    --cc=jordanp@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).