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


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: spacibba <at> aol.com, 78520 <at> debbugs.gnu.org
Subject: Re: bug#78520: 31.0.50;
 Performance issue in dired+isearch with dired-isearch-filenames
Date: Wed, 21 May 2025 15:38:59 +0300
> Cc: spacibba <at> aol.com
> From: Juri Linkov <juri <at> linkov.net>
> Date: Wed, 21 May 2025 09:20:43 +0300
> 
> > I have been using dired and isearch in a directory with ~8000 files and
> > emacs became totally non-responsive. It freezed with every letter for
> > ~10 seconds.
> >
> > I checked my config and it seems that the problem is
> > `dired-isearch-filenames`. Any non-nil value produces this issue.
> 
> When you customize `dired-isearch-filenames` to non-nil, it uses
> `next-single-property-change` to restrict matches to filenames.

I guess this could be slow in a buffer with a lot of properties?

Would it be possible to speed this up by searching as usual, but then
rejecting matches whose positions don't have the 'filename' property?
Or was this tried and found to be not faster?




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.