bug#64735: 29.0.92; find invocations are ~15x slower because of ignores

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Dmitry Gutov <dmitry@gutov.dev>, luangruo@yahoo.com,
>  sbaugh@janestreet.com, 64735@debbugs.gnu.org
> Date: Thu, 27 Jul 2023 08:20:55 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Skipping regexp matching entirely, though, will make this benchmark 
> >> farther removed from real-life usage: this thread started from being 
> >> able to handle multiple ignore entries when listing files (e.g. in a 
> >> project).
> >
> > Agreed.  From my POV, that variant's purpose was only to show how much
> > time is spent in matching file names against some include or exclude
> > list.
> 
> Yes and no.
> 
> It is not uncommon to query _all_ the files in directory and something
> as simple as
> 
> (when (and (not (member regexp '("" ".*"))) (string-match regexp file))...)
> 
> can give considerable speedup.

I don't understand what you are saying.  The current code already
checks PREDICATE for being nil, and if it is, does nothing about
filtering.

And if this is about testing REGEXP for being a trivial one, adding
such a test to the existing code is trivial, and hardly justifies an
objection to what I wrote.

> > There's a possibility of pushing this filtering into
> > file-name-all-completions, but I'm not sure that will be faster.  We
> > should try that and measure the results, I think.
> 
> Isn't `file-name-all-completions' more limited and cannot accept
> arbitrary regexp?

No, see completion-regexp-list.