GNU bug report logs - #78520
31.0.50; Performance issue in dired+isearch with dired-isearch-filenames

Previous Next

Full log

Message #77 received at 78520 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 78520 <at> debbugs.gnu.org, spacibba <at> aol.com
Subject: Re: bug#78520: 31.0.50; Performance issue in dired+isearch with
 dired-isearch-filenames
Date: Wed, 04 Jun 2025 09:12:18 +0300

>> But let me check for my local changes to the repo first.  Maybe there
>> is a culprit.
>
> Ok - good news: it was just that.

Good.

> I had a pending fix for Bug#73018 that caused the bad performance.
> Without it I see a very good performance.

Does the problem reported in bug#73018 still exist?

>> > Do we need more optimization for such rare cases?
>> Not really worth it I think.
>
> But if you want to give it a try, don't hesitate either.  If the user
> happens to search for something like the user or group name in
> file names, the behavior is annoying.  And a confusing surprise.
> So even if it's a corner case, I think it could be worth trying to
> improve this, given you have the time.

Searching the user name in file names is too rare use case,
and still can be fast when starting the search outside of filenames,
i.e. using the default search function.

> One small thing I noticed (but that does not have a large impact) was
> that `search-within-boundaries' is called repeatedly, and the binding
> #+begin_src emacs-lisp
> (subregexp
>   (and isearch-regexp
>        (save-match-data
>          (catch 'subregexp
>            (while (string-match "\\^\\|\\$" string i)
>              (setq i (match-end 0))
>              (when (subregexp-context-p string (match-beginning 0))
>                ;; The ^/$ is not inside a char-range or escaped.
>                (throw 'subregexp t)))))))
> #+end_src
> is computed every time with the same bindings in effect.  This could
> maybe be factored out (i.e., the computation could maybe be moved
> upwards in the call tree).

This would require adding a new buffer-local variable
with an ad-hoc name.

Previous Next

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