GNU bug report logs -
#78520
31.0.50; Performance issue in dired+isearch with dired-isearch-filenames
Previous Next
Reported by: Ergus <spacibba <at> aol.com>
Date: Tue, 20 May 2025 23:34:02 UTC
Severity: normal
Tags: fixed
Found in version 31.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Full log
Message #77 received at 78520 <at> debbugs.gnu.org (full text, mbox):
>> 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.
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.