From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#71355: 30.0.50; [PATCH] Improve performance of buffered output in Eshell Date: Wed, 5 Jun 2024 11:47:40 -0700 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12537"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71355@debbugs.gnu.org, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 05 20:58:07 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 1sEvpn-00035b-GN for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Jun 2024 20:58:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sEvpV-0006Cx-Qt; Wed, 05 Jun 2024 14:57: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 1sEvpU-0006CZ-Iz for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 14:57: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 1sEvpT-0003ea-Kl for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 14:57:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sEvph-00025o-NS for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2024 14:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Jun 2024 18:58: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.17176138607991 (code B ref 71355); Wed, 05 Jun 2024 18:58:01 +0000 Original-Received: (at 71355) by debbugs.gnu.org; 5 Jun 2024 18:57:40 +0000 Original-Received: from localhost ([127.0.0.1]:57435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sEvpL-00024m-KB for submit@debbugs.gnu.org; Wed, 05 Jun 2024 14:57:40 -0400 Original-Received: from mail-qv1-f43.google.com ([209.85.219.43]:47374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sEvpJ-00024N-2J for 71355@debbugs.gnu.org; Wed, 05 Jun 2024 14:57:38 -0400 Original-Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-6ae2e6dba36so693796d6.3 for <71355@debbugs.gnu.org>; Wed, 05 Jun 2024 11:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717613777; x=1718218577; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=ekjATJGKu4MjeDRTTI+XZEYmS7d7MqoNu6w/qlzrRk0=; b=jlwOdKfW12ZMxsaG/PP6I6wgtMb8I9zQZh8KMLOqemRINCGKAT+kIlJVU941ehC78l vVh9AkbwuAyFr9LZdmeh8N4r8AOZLkU7j1BUTzt2Wg+6UI/RAWyBiuxutUc5g159TdpD EdgKeOXbGi38qyhIxS7+pK2eMGutdQQI/FWab0MaTpuidLgZz0KcefFjVWA5l1FdprXw hLUh3PQQy3fsA42zD8a13anV8wC4z3esLSqOE+2uFHptDci8LHK6vEKs5j6kHQxGom6p wJBh5WE00ABGmQlJ60+kt5lF1R90ORupH2P6l0dr7kXY7nO1tU5KNVbbS95Vdd2rvnt9 yeIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717613777; x=1718218577; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ekjATJGKu4MjeDRTTI+XZEYmS7d7MqoNu6w/qlzrRk0=; b=OjHS/A3DgVKVdqukPPsNdkmJVVTPAnBXYrEGwELMIgzKsCvLDFrohkomihVrJfR9u1 n2hF7/MkdswdUJXyyiVdin102+JsFQq33JB52HnlkHqfTQbOvbI9pHf6lC93z8qjvb97 cuWfTlMn4Bv4fpErq9+Pknd8qX2e6CHB6jTb/atRAmdGUcjKBYUVLcD+q85MK25t+OhO p4+fYRfQUzxx7CP/22ZMDZn4R2udjOZZilCNYRzJqXwPML/f9C/Kmg5RfMNWGu/pss6Z 8C8q4sFM5F/C59cxNIVAY6thhPV7jBL2UljvL66+5CZrimKs0NLfbhxZLjjN1cicNad1 U6wA== X-Gm-Message-State: AOJu0YwjoGg+KOAUQOaVFfxtP+NIRM8oV3+o+Fr4w1OX6tT0V83AI9Ie eTCeGGGd1xpQJV4Rgq3A7BVbG+YYn3QQK2wQ8Z+fjh2cVWtwIVzjV7J22w== X-Google-Smtp-Source: AGHT+IFhHEjDr9cEyY+oQhOZZcZqs8kIlSIpWfzud5kywSRRG1CgHoyrVclU2sST4MK/2g7W1oXvTw== X-Received: by 2002:a17:90a:a515:b0:2bd:f751:e18c with SMTP id 98e67ed59e1d1-2c27db190d3mr3200224a91.27.1717613262424; Wed, 05 Jun 2024 11:47:42 -0700 (PDT) Original-Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id 98e67ed59e1d1-2c28066cfc9sm1804627a91.22.2024.06.05.11.47.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Jun 2024 11:47:41 -0700 (PDT) Content-Language: en-US In-Reply-To: <86y17ji860.fsf@gnu.org> 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:286636 Archived-At: On 6/5/2024 10:57 AM, Eli Zaretskii wrote: > 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. You had asked about changing the buffer size; in my initial explanation, I was just trying to explain my reasoning for why a larger buffer size improves the overall execution time. So I was only talking about the performance (the redisplay changes are mostly independent from the buffer size setting, since I throttle the redisplays by time). To be more precise though: the current code writes text into the *buffer* in chunks of 5 lines. (That text will end up on the screen at the next redisplay, whenever that is.) With my patch, if I set the buffer size to 128, it will write text into the buffer every 128 chars, which results in a similar number of write operations as before the patch. Since those write operations are what makes the current code slow, a 128-char buffer with my patch is similarly slow. > 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. Correct. The redisplay logic is a new behavior, and not *directly* a part of the performance improvements I made by increasing the buffer size. On the contrary, I added the redisplay logic because the buffer size improvements made the total execution time so much better that I felt Eshell could now afford the extra cost of redisplaying periodically for these commands.