GNU bug report logs - #48581
27.2; Default value of lazy-highlight-buffer-max-at-a-time is too low

Previous Next

Full log

View this message in rfc822 format

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48581 <at> debbugs.gnu.org
Subject: bug#48581: 27.2; Default value of lazy-highlight-buffer-max-at-a-time is too low
Date: Sat, 22 May 2021 12:49:16 +0200

On Sat, 22 May 2021 at 12:44, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Date: Sat, 22 May 2021 11:25:44 +0200
>> 
>> The value of lazy-highlight-buffer-max-at-a-time determines how long
>> it takes to finish computing the isearch lazy count.  The current
>> default value of 20 seems suboptimal.
>> 
>> I made a simple experiment measuring the (real) time to count the
>> ~15000 matches of the string "e" in the file isearch.el, with the
>> following results:
>> 
>> lazy-highlight-buffer-max-at-a-time | time to finish counting
>> 20 (current setting)                | 1.5 s
>> 50                                  | 0.8 s
>> 100                                 | 0.6 s
>> 200                                 | 0.5 s
>> nil (do it all at once)             | 0.4 s
>> 
>> Based on this, I would like to suggest changing the default to 200, or
>> something in that order of magnitude.
>
> You assume that (a) the main purpose of Isearch is to count the
> matches,

No, the main purpose of Isearch is to search for a string :-).
`isearch-lazy-highlight-buffer-update' has more than one purpose, but I
assume that finishing faster is always better than taking longer than
necessary.

> and (b) that a case with 15,000 matches is the common one?

No, that was just so I that the measured time is not too small.

However, the delay before the lazy count appears in the echo area during
day-to-day Isearch operation is noticeable to the naked eye.  If you
keep looking, you will notice it.

Note that the precise value of this parameter is irrelevant, only the
order of magnitude plays a significant role.  I don't think there's a
need to do a more formal benchmark to conclude 20 is to small and 2000
is probably too big.

>
>> The downside of this change would be an increase in the time Emacs is
>> unresponsive doing lazy counting/highlighting.  However, this time
>> remains below a few milliseconds in a typical case
>
> What kind of CPU do you have there,

A decent but not particularly powerful laptop from 2019.

> and how many milliseconds does it take Emacs to highlight 20 vs 200
> matches?

I didn't specifically compute that, but you can get an upper bound based
on the provided data: 2 ms for 20 matches and 6.7 ms for 200 matches.

Previous Next

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