From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Excessive redisplay from lots of process output Date: Fri, 17 Feb 2023 18:06:01 +0200 Message-ID: <834jrk1dli.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12988"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, azeng@janestreet.com To: Spencer Baugh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 17 17:06:25 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 1pT3Fe-0003AG-U7 for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Feb 2023 17:06:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pT3FL-00068F-MR; Fri, 17 Feb 2023 11:06:03 -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 1pT3FK-00062e-2w for emacs-devel@gnu.org; Fri, 17 Feb 2023 11:06:02 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pT3FJ-0001PS-Il; Fri, 17 Feb 2023 11:06:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=iPXOeyCpxF+yCOBAynNjGT0RRwBk2RDtCI4u4cmjObs=; b=nAAxIEm9iSwf SAUk63kVEqau/bYdNPBNnIZxLTiUEmFQmTc9KkQHUNVj3ss0wyX0BU2qtn5KH8Nypg1j2Zr9McLAF GQkoXhGkIsx4QJopETLgSXZmLys8VNczPx8FLw/jG6KgvPKf6nYHV7xrUjYN99zAoKDLb5xbZJm6E 0S5KQWS/mGTzsJFdKpjjGPZ/DYdgKrEqk4AIX0diLQ3KJb0CCaApuHVnC5oNbsvXQMZSvad+J8IQy Rrz7QkJJcZZ7ojWZU3UC5+sxy1WU1JMsvm0kgml4Um0Qy4iKMRhBIRsOckSnekcRXEDFxBeUkfx0n +vj+ujAn80F/gmYIe7FGOQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pT3FI-0004qG-VA; Fri, 17 Feb 2023 11:06:01 -0500 In-Reply-To: (message from Spencer Baugh on Fri, 17 Feb 2023 10:16:11 -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:303502 Archived-At: > From: Spencer Baugh > 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.) 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? > 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. You are thinking in the wrong direction. You assume that if redisplay is called frequently, it will necessarily slow down Emacs. That assumption is false: redisplay works very hard to avoid expensive processing when it can. So reducing the frequency of calls to redisplay is not the right direction to make progress in your and other similar cases.