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 #17 received at 78520 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Thu, 22 May 2025 09:33:20 +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?

In a Dired buffer the property 'dired-filename' is almost on every line.

> 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?

The currently implementation was intended to be quite fast,
and indeed when I try it on a dir with thousands of files,
isearch-lazy-highlight takes only 1 sec, even with thousands of matches.
But apparently on slower hardware it's more slow.  So unless someone wants
to make an effort to optimize the implementation more, IMHO this could be closed.




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.