From: Spencer Baugh <sbaugh@janestreet.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org, azeng@janestreet.com
Subject: Re: Excessive redisplay from lots of process output
Date: Fri, 17 Feb 2023 11:41:27 -0500 [thread overview]
Message-ID: <CAO=BR8Px3i-q4yPS9skQU4W2j964NEcVWKpkWWExpw7cc27fkQ@mail.gmail.com> (raw)
In-Reply-To: <834jrk1dli.fsf@gnu.org>
On Fri, Feb 17, 2023 at 11:06 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Spencer Baugh <sbaugh@janestreet.com>
> > Cc: azeng@janestreet.com
> > Date: Fri, 17 Feb 2023 10:16:11 -0500
> >
> > Emacs calls redisplay every time it reads process output. This causes
> > Emacs to become painfully slow when these two conditions are met:
> >
> > - When redisplay is expensive (e.g. when using ssh X forwarding)
> >
> > - And when there is frequent process output, say hundreds or thousands
> > of times a second (e.g. ERC receiving network traffic, shells
> > running commands which log heavily, other things which run in the
> > background)
>
> This cannot be the whole story, because usually redisplay exits almost
> immediately after being called, having determined that nothing needs
> to be changed on display.
>
> So the important part of your situation that you didn't disclose is:
> why does Emacs in your case perform the expensive redisplay each time
> redisplay is entered? Can you figure that out by stepping through
> redisplay_internal? (Let me know if you need guidance.)
Oh, this was the key information for me to realize what was *really*
going on. In Emacs 27, in-progress key sequences get replayed each
time there is process output to read, see bug#32922. This causes
redisplay to have actual work to do each time it reads process output.
But this only happens mid key-sequence, so it's not really a general
issue with Emacs performance, but it *does* cause the X server to get
swamped and therefore slows down X in general, including the window
manager and other X clients.
But fortunately that key-sequence replaying behavior was deleted in
Emacs 28, just as a general cleanup, see bug#5803. Which helpfully
means that redisplay is once again always cheap, so the bad X
performance of having lots of process output disappears.
Sorry, a mix of upgrading to Emacs 28 and also applying this patch
made it not clear what was helping performance. But now it is clear.
> Not sure here is the right place for this kind of discussion, btw. It
> might be better to submit a bug report with all the relevant details,
> and discuss this on the bug tracker.
>
> > I realize that reading process output can trigger filters which can
> > change window and frame configurations, which in turn means redisplay
> > needs to happen. But isn't there some way we could improve this
> > situation? Right now these redisplays are causing serious
> > user-visible performance degradation.
>
> There are many variables and flags Emacs uses to decide when something
> changed that needs the display to be updated. Those should generally
> prevent Emacs from running the expensive parts of redisplay if they
> are unnecessary. The question is why this doesn't work in your case.
>
> IOW, it is better to consider this as some specific failure in some
> particular situation, and find why it happens, instead of considering
> this as some general failure of the Emacs design. Design-wise, things
> are fine; it's something in your specific case that could fail the
> existing mechanisms, and the question is: what is that and why it
> fails?
Oh yes, that makes sense, now I see, thanks for the explanation.
next prev parent reply other threads:[~2023-02-17 16:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-17 15:16 Excessive redisplay from lots of process output Spencer Baugh
2023-02-17 16:06 ` Eli Zaretskii
2023-02-17 16:41 ` Spencer Baugh [this message]
2023-02-24 19:14 ` Spencer Baugh
2023-02-24 19:34 ` Eli Zaretskii
2023-02-24 20:08 ` Spencer Baugh
2023-02-24 20:19 ` Eli Zaretskii
2023-02-24 20:33 ` Spencer Baugh
2023-02-24 20:51 ` Eli Zaretskii
2023-02-24 23:14 ` Po Lu
2023-02-24 23:10 ` Po Lu
2023-02-25 7:35 ` Eli Zaretskii
2023-02-25 9:43 ` Po Lu
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='CAO=BR8Px3i-q4yPS9skQU4W2j964NEcVWKpkWWExpw7cc27fkQ@mail.gmail.com' \
--to=sbaugh@janestreet.com \
--cc=azeng@janestreet.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.