GNU bug report logs - #71576
30.0.50; [PATCH] Improve performance of Comint/Eshell password prompt handling

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Jim Porter <jporterbugs <at> gmail.com>
Subject: bug#71576: closed (Re: bug#71576: 30.0.50; [PATCH] Improve
 performance of Comint/Eshell password prompt handling)
Date: Fri, 21 Jun 2024 00:44:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 71576 <at> debbugs.gnu.org.

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

[Message part 2 (message/rfc822, inline)]

From: Jim Porter <jporterbugs <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>, 71576-done <at> debbugs.gnu.org
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.

[Message part 3 (message/rfc822, inline)]

From: Jim Porter <jporterbugs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; [PATCH] Improve performance of Comint/Eshell password prompt
 handling
Date: Sat, 15 Jun 2024 12:50:01 -0700

[Message part 4 (text/plain, inline)]

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 (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.