unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Augusto Stoffel <arstoffel@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 48581@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	[thread overview]
Message-ID: <87eedzujpv.fsf@gmail.com> (raw)
In-Reply-To: <83eedzksqj.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 22 May 2021 12:44:36 +0300")

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

>> From: Augusto Stoffel <arstoffel@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.





  reply	other threads:[~2021-05-22 10:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-22  9:25 bug#48581: 27.2; Default value of lazy-highlight-buffer-max-at-a-time is too low Augusto Stoffel
2021-05-22  9:44 ` Eli Zaretskii
2021-05-22 10:49   ` Augusto Stoffel [this message]
2021-05-22 11:08     ` Eli Zaretskii
2021-05-22 12:17       ` Augusto Stoffel
2021-05-22 12:30         ` Eli Zaretskii
2021-05-22 13:14           ` Augusto Stoffel
2021-05-22 13:35             ` Eli Zaretskii
2021-05-25 20:29 ` Juri Linkov
2021-05-31 20:33   ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87eedzujpv.fsf@gmail.com \
    --to=arstoffel@gmail.com \
    --cc=48581@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).