Subject: bug#78520: 31.0.50; Performance issue in dired+isearch with dired-isearch-filenames

From: Juri Linkov <[email-masked]>
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'.