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

[Dmitry Gutov]

On 23/07/2023 20:56, Eli Zaretskii wrote:
> > Date: Sun, 23 Jul 2023 20:46:19 +0300
> > Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net,
> >   64735@debbugs.gnu.org
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > On 23/07/2023 14:18, Eli Zaretskii wrote:
> > > > Date: Sun, 23 Jul 2023 13:46:30 +0300
> > > > Cc:luangruo@yahoo.com,sbaugh@janestreet.com,yantar92@posteo.net,
> > > >    64735@debbugs.gnu.org
> > > > From: Dmitry Gutov<dmitry@gutov.dev>
> > > >
> > > > On 23/07/2023 08:11, Eli Zaretskii wrote:
> > > > > Even better: compute completion-regexp-list so that IGNOREs are
> > > > > filtered by file-name-all-completions in the first place.
> > > > We don't have lookahead in Emacs regexps, so I'm not sure it's possible
> > > > to construct regexp that says "don't match entries A, B and C".
> > > Well, maybe just having a way of telling file-name-all-completions to
> > > negate the sense of completion-regexp-list would be enough to make
> > > that happen?
> >
> > Some way to do that is certainly possible (e.g. a new option and
> > corresponding code, maybe; maybe not), it's just that the person
> > implementing it should consider the performance of the resulting solution.
>
> I agree.  However, if we are going to implement filtering of file
> names, I don't think it matters where in the pipeline to perform the
> filtering.

A possible advantage of doing it earlier, is that if filtering happens 
in C code you could do it before allocating Lisp strings, thereby 
lowering the resulting GC pressure at the outset.