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: Wed, 05 Jun 2024 20:57:59 +0300 Message-ID: <86y17ji860.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21117"; 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 Wed Jun 05 19:59:05 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 1sEuuf-0005GY-03 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Jun 2024 19:59:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sEuuQ-0006Lf-6O; Wed, 05 Jun 2024 13:58:50 -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 1sEuuO-0006KG-79 for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 13:58: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 1sEuuN-00048x-UY for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 13:58:47 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sEuub-0007tK-Nt for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 13:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Jun 2024 17:59:01 +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.171761030730251 (code B ref 71355); Wed, 05 Jun 2024 17:59:01 +0000 Original-Received: (at 71355) by debbugs.gnu.org; 5 Jun 2024 17:58:27 +0000 Original-Received: from localhost ([127.0.0.1]:53312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sEuu2-0007rr-Mn for submit@debbugs.gnu.org; Wed, 05 Jun 2024 13:58:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sEuu1-0007rV-1Y for 71355@debbugs.gnu.org; Wed, 05 Jun 2024 13:58:25 -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 1sEuth-0003yw-JA; Wed, 05 Jun 2024 13:58:05 -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=S1FoI0hJ7xdES7yaIlzzhHe8wMxxJiuGyONtb6pl8Vs=; b=D8ncdPZOQcCN ht2Mu98Ftw8JDz3J7oAuWrbqOFwwNwexe+YmCOJtuinZc5ng+p7+7q2yQj1hvCV0u3mLs1r49oM0j UbP+vqha5+JOdGhibslnIGJMRjtin3kwgzsxQsYEsye+ZCxrdOri4gVDd7XYk1gTrUuma8riq0urN gUSGHocxRWu9gPXuREXE9I/28KPEpHlr2aejrEcTgmB22Av/I6Kmlp0PEGkbDxiRXwf0Shjzn9CO3 w4hW8La7Wh8mDXqlXiwVXuqLXLq7dynj0qwctX2aZdpnQNR97Dhi4exgmnVaveX7wpEfCy3CPQ75A UjhoROPchcszAvgt7O/AnQ==; In-Reply-To: <9da5a395-48e8-fb20-145b-1d2581315fcf@gmail.com> (message from Jim Porter on Wed, 5 Jun 2024 10:35:08 -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:286633 Archived-At: > Date: Wed, 5 Jun 2024 10:35:08 -0700 > Cc: 71355@debbugs.gnu.org, stefankangas@gmail.com > From: Jim Porter > > On 6/5/2024 9:51 AM, Eli Zaretskii wrote: > >> Date: Wed, 5 Jun 2024 09:42:43 -0700 > >> Cc: 71355@debbugs.gnu.org, stefankangas@gmail.com > >> From: Jim Porter > >> > >> On 6/5/2024 5:06 AM, Eli Zaretskii wrote: > >>> Is 2K indeed the optimal size? It is about 25 80-column lines, which > >>> is quite a lot. "Normal" shells send output to the screen in smaller > >>> chunks. How about 128 instead? or maybe some small multiple of the > >>> line length, like 1 or 2? > >> > >> Yes, I believe 2k is the optimal size, or close to it. Trying a value of > >> 128 results in basically no change in performance from baseline. That > >> makes sense to me, since 128 is actually fairly close to the old value > >> for this buffering (which was five *lines*[1]; the old code measured > >> this differently). > > > > That's strange, because I see no output at all until all of it is > > available and showsn, and I thought you said the same in your OP? > > Yes, without my patch that's expected. When I talk about changes in > performance, I mean the total time to complete the command, as measured > by, e.g. "time cat config.log". > > Here's what's happening: all of the output in 'eshell/cat' occurs in a > loop, periodically calling 'eshell-interactive-print' (how often it > calls this depends on the buffering settings). That runs the functions > in 'eshell-output-filter-functions', which can be fairly expensive. So > one way to make output faster would be to optimize those functions, > which I did in my second patch. However, a larger buffer size is still > faster even when there are no output filter functions, due to other > overheads in the code. So I think even if we could make > 'eshell-output-filter-functions' all very cheap, it's worth increasing > the buffer size. > > In addition to this, the performance improvements I made allowed me to > add in the extra work of redisplaying periodically when using this > buffered output scheme. That's all new in my patch, and previously you'd > have to wait until the command was finished to see any output. From > Emacs's perspective, everything in 'eshell/cat' is synchronous, so I > needed to manually trigger the redisplay (or do some other sorcery to > hand control back to the command loop). I think we are miscommunicating. I wasn't talking about performance, I was talking about the fact that I don't see text delivered to the screen in chunks. You said that the current code sends text to the screen in chunks of 5 lines, and that therefore using the value 128 is almost the same. But at least part of your patch calls redisplay after each chunk (AFAIU), something that is not done with the current code. So I expect the effect to be a difference in behavior, whereby test appears on the screen in chunks, and the user does not need to wait till all of it is sent before he/she sees anything at all displayed. I hope I've succeeded to explain myself now.