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.bugs Subject: bug#71355: 30.0.50; [PATCH] Improve performance of buffered output in Eshell Date: Thu, 06 Jun 2024 07:43:58 +0300 Message-ID: <86r0daistt.fsf@gnu.org> References: <22b0dc8f-11dc-5fd2-c75d-88c17580d28d@gmail.com> <848772e9-5ef0-8a8a-decd-c0b79366ec27@gmail.com> <86ikynk30i.fsf@gnu.org> <037ebce9-93af-f1ad-67d9-550fd1074294@gmail.com> <8634prjpt0.fsf@gnu.org> <9da5a395-48e8-fb20-145b-1d2581315fcf@gmail.com> <86y17ji860.fsf@gnu.org> <86v82ni5dd.fsf@gnu.org> <7f6b9173-e16f-c65d-8758-8ca7098876b7@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18695"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71355@debbugs.gnu.org, stefankangas@gmail.com To: Jim Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 06 07:23:17 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sF5an-0004eG-Ei for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Jun 2024 07:23:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sF5aL-0000e7-RP; Thu, 06 Jun 2024 01:22:49 -0400 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 1sF5aK-0000di-9h for bug-gnu-emacs@gnu.org; Thu, 06 Jun 2024 01:22:48 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sF5aK-0006Qy-2d for bug-gnu-emacs@gnu.org; Thu, 06 Jun 2024 01:22:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sF5aY-000703-68 for bug-gnu-emacs@gnu.org; Thu, 06 Jun 2024 01:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Jun 2024 05:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71355 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 71355-submit@debbugs.gnu.org id=B71355.171765134226818 (code B ref 71355); Thu, 06 Jun 2024 05:23:02 +0000 Original-Received: (at 71355) by debbugs.gnu.org; 6 Jun 2024 05:22:22 +0000 Original-Received: from localhost ([127.0.0.1]:38922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sF5Zu-0006yT-0X for submit@debbugs.gnu.org; Thu, 06 Jun 2024 01:22:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sF5Zr-0006xi-13 for 71355@debbugs.gnu.org; Thu, 06 Jun 2024 01:22:19 -0400 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 1sF4ym-0008GS-Lf; Thu, 06 Jun 2024 00:44:01 -0400 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=zjWh4jVpQbocjLWH4VS+h8sPDPnyw3hJXlhMVmWM7gc=; b=P08QuEF7JfkL J1+R9CuqW+esDI1wkKy133xIejxw3UNnXuNvtgpBLDPT3+dltZRIHNAIl1Ve3oA+ysgRP6YD8w5W6 peRRUrpLUxqsQMcWPs+u1TN8pUTOO1Cyc+z5HKVI45CDi/aEzbB0E694B00fx0SHtTyaCQ3lc0oj5 6IHtV48E0+NQwxTNS5jQjAxtcE7TOWwXgJ7OPOOTcIq7UO4puutkQX0uNcmxyfYGYzHXqBLPw2HmY 2gawn/41WDVZgAgtNPtT0xI0FhZ6faSb6YWY2ieyFyZaXvCGN18l2CGisGGZ7a/wv7KHWseKRU4i1 IrzKfNZD8czwnmxiB+3gMQ==; In-Reply-To: <7f6b9173-e16f-c65d-8758-8ca7098876b7@gmail.com> (message from Jim Porter on Wed, 5 Jun 2024 13:07:48 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286648 Archived-At: > Date: Wed, 5 Jun 2024 13:07:48 -0700 > Cc: 71355@debbugs.gnu.org, stefankangas@gmail.com > From: Jim Porter > > On 6/5/2024 11:58 AM, Eli Zaretskii wrote: > > So now that we agree about this aspect, I ask again: wouldn't it make > > sense to show the text to the user in smaller chunks? 2K characters > > is 2 dozen lines, and I expect users to be somewhat unhappy about > > being presented the text in such large chunks. That's now what they > > see when invoking 'cat' from the shell prompt outside Emacs. > > Ok, I see what you mean. I think the thing users would be unhappy about > is "long" periods of time between display updates. (If we flush and/or > redisplay faster than the user's monitor refreshes, those updates are > wasted.) > > For the kinds of output that Eshell's buffered-print is designed for, we > can get the text we want to print very quickly, so even with a buffer > size of 2048, we flush more than 60 times a second (testing with "cat" > and "ls" on a spinny disk). In situations where the buffering caused > unacceptable delays, a command would either a) not use buffered output > or b) manually flush at opportune times. I'm not sure those would come > up in practice though. > > Ultimately, in the cases where Eshell does buffered-printing now, the > thing that limits the user seeing updates is the redisplay throttle, not > the buffer size. > > A smarter version of 'eshell-buffered-print' could flush before the > buffer was full if enough time has passed, but that would add complexity > without a lot of immediate benefit. (For example, would we set up a > timer to flush? I'm not sure how that would interact with the rest of > this code, which is all synchronous.) My main point is that 'cat' is used to show the contents of a file to the user, so the assumption is that the user _wants_ to see that stuff. So having the stuff flash before user's eyes in an instant is not necessarily the best idea, even though it is faster, and thus performance-wise we win. If the above is agreed, and you still think 2K characters is the best default value, I'm fine with that.