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

Previous Next

Package: emacs;

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


View this message in rfc822 format

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

> I'm using C-s in large Dired buffers all the time, and before the patch
> the search lags were too long (~2 sec on every match).  But now with
> the patch the search is instantaneous even on very large Dired
> buffers.

I do have a very large buffer, and in emacs -Q the first match is not
found before at least 10 or 15 seconds have passed.  I have a somewhat
older laptop, but definitely not that slow.

> The search might be still slow only on one very rare case:
> when the search string also occurs outside of file names.
> For example, when the Dired contains permissions "-rw-r--r--",
> then searching for "r" or "rw" will be slow.

I know.  That's not what I did.  I had started the search using
M-s f C-s, not C-s, however.  But let me check for my local changes to
the repo first.  Maybe there is a culprit.

> Do we need more optimization for such rare cases?

Not really worth it I think.

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).


Michael.




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.