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

Previous Next

Full log

View this message in rfc822 format

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: bug#78520: 31.0.50; Performance issue in dired+isearch with dired-isearch-filenames
Date: Thu, 22 May 2025 19:58:07 +0300

>> 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.
>
> I have fast hardware, but C-s for a match near the end of a Dired
> buffer showing 5K files takes about 9 sec.  This is in an unoptimized
> build; an optimized build still takes 2.25 sec.

I see the same in an optimized build: ~2 sec until isearch-lazy-count
shows the number of matches (~5000).

> I'm not sure why you are talking about isearch-lazy-highlight, that's
> not what the original report is about.  C-s is slow even if I turn off
> isearch-lazy-highlight, and the profile below in that case still
> points to next-single-property-change as the hot spot.

I see no delay when isearch-lazy-highlight is disabled.

>> So unless someone wants to make an effort to optimize the
>> implementation more, IMHO this could be closed.
>
> Does isearch.el have some infrastructure for examining a match and
> rejecting it if it doesn't meet some criteria?  If so, can you point
> me to that infrastructure?

Everything is in 'search-within-boundaries' where 'next-fun'
is a lambda from 'isearch-search-fun-in-text-property'
that uses 'next-single-property-change'.

Previous Next

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