bug#71576: closed (30.0.50; [PATCH] Improve performance of Comint/Eshell password prompt handling)

[GNU bug Tracking System]

Your message dated Thu, 20 Jun 2024 17:42:36 -0700
with message-id <eb1e6d98-8379-d25e-f7e0-8c08eb5dffc7@gmail.com>
and subject line Re: bug#71576: 30.0.50; [PATCH] Improve performance of 
Comint/Eshell password prompt handling
has caused the debbugs.gnu.org bug report #71576,
regarding 30.0.50; [PATCH] Improve performance of Comint/Eshell password prompt 
handling
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
71576: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71576
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: 30.0.50; [PATCH] Improve performance of Comint/Eshell password prompt handling Date: Sat, 15 Jun 2024 12:50:01 -0700 How long can a password prompt really be? In Comint and Eshell, we check for output from subprocesses that looks like a password prompt, so that we can hide the password when the user types it in. That's good, but for commands that output a lot of text, it can take a while to scan through it all.

The attached patch adds a performance optimization for this: since we only check for password prompts at the end of a block of output (the subprocess is presumably waiting for the user to type in their password), we only need to look at the last N characters, where N is whatever the maximum password prompt length is. There's obviously no *strict* maximum here, but I can't imagine a password prompt being longer than 256 characters. Compared to the default 'read-process-output-max' value of 4096, this means we could skip up to 93% of the output when looking for the prompt.

In practice, this optimization makes us about 25% faster at outputting large amounts of text. For example, in shell-mode, "cat config.log" gives me the following results:

 BEFORE |  AFTER
--------+-------
  3.852 |  2.890
  3.728 |  2.771
  3.568 |  2.716

The results in Eshell are pretty similar, too.

I've added NEWS entries for this, although maybe this isn't something that really needs to be announced. Still, I figured it was worth mentioning in the unlikely case that the new behavior could cause some problem with (very!) long password prompts.

I'm also totally fine with letting this patch wait for Emacs 31 if there's any concern about the code. It's not a big change, but maybe it's worth erring on the side of stability.

0001-Limit-the-amount-of-text-we-examine-when-looking-for.patch
Description: Text document

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#71576: 30.0.50; [PATCH] Improve performance of Comint/Eshell password prompt handling
>
>
>
>
> Date: 
>
> Thu, 20 Jun 2024 17:42:36 -0700
>
>
>
>
> On 6/16/2024 3:53 AM, Stefan Kangas wrote:
> > Thanks.  I'd be okay with putting this patch in Emacs 30, but let's see
> > what other people think.
> [snip]
> > If this is hardcoded in Tramp, are we sure that we need this as an
> > option?  I'd suggest making it into a defconst or defvar instead.
>
> Since no one else has expressed any concerns, I've merged this as 
> 1a55e957ae5 to the master branch, replacing the defcustoms with defvars.
>
>
> --- End Message ---