From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Excessive redisplay from lots of process output Date: Fri, 17 Feb 2023 10:16:11 -0500 Message-ID: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38223"; mail-complaints-to="usenet@ciao.gmane.io" Cc: azeng@janestreet.com To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 17 16:49:07 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pT2yv-0009pT-Vn for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Feb 2023 16:49:05 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pT2y3-0000cb-Uu; Fri, 17 Feb 2023 10:48:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pT2T8-0004lh-1M for emacs-devel@gnu.org; Fri, 17 Feb 2023 10:16:14 -0500 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pT2T6-0001VC-Hx for emacs-devel@gnu.org; Fri, 17 Feb 2023 10:16:13 -0500 Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 17 Feb 2023 10:48:10 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303499 Archived-At: 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