unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: emacs-devel@gnu.org
Cc: azeng@janestreet.com
Subject: Excessive redisplay from lots of process output
Date: Fri, 17 Feb 2023 10:16:11 -0500	[thread overview]
Message-ID: <ierk00gl3us.fsf@janestreet.com> (raw)


Hi emacs-devel,

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)

Does Emacs really need to redisplay on every process output?  I've
installed the following change in my Emacs, which has radically
reduced the amount of redisplay performed and improved performance,
and I haven't noticed any adverse effects:

--- a/src/process.c
+++ b/src/process.c
@@ -5804,8 +5804,6 @@ wait_reading_process_output (intmax_t time_limit,
 		  FD_ZERO (&Available);
 		  last_read_channel = channel;
 
-		  if (do_display)
-		    redisplay_preserve_echo_area (12);
 		}
 	      else if (nread == -1 && would_block (errno))
 		;
-- 


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.

One idea: Could we allow Lisp code to mark a process as not wanting
redisplay after Emacs reads output?  Then packages which receive heavy
amounts of process output could mark their processes in this way.  If
they do rarely need to perform user-visible changes, they could
explicitly call (redisplay) themselves.

Thoughts on this problem and any potential solutions for it?

Thanks,
Spencer Baugh



             reply	other threads:[~2023-02-17 15:16 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 15:16 Spencer Baugh [this message]
2023-02-17 16:06 ` Excessive redisplay from lots of process output Eli Zaretskii
2023-02-17 16:41   ` Spencer Baugh
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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=ierk00gl3us.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=azeng@janestreet.com \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).