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

[Dmitry Gutov]

On 25/07/2023 22:16, sbaugh@catern.com wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> > > (my-bench 1 default-directory "")
> >
> > (("built-in" . "Elapsed time: 1.601649s (0.709108s in 22 GCs)")
> >   ("with-find" . "Elapsed time: 1.792383s (1.135869s in 38 GCs)")
> >   ("with-find-p" . "Elapsed time: 1.248543s (0.682827s in 20 GCs)")
> >   ("with-find-sync" . "Elapsed time: 0.922291s (0.343497s in 10 GCs)"))
>
> Tangent, but:
>
> Ugh, wow, call-process really is a lot faster than make-process.  I see
> now why people disliked my idea of replacing call-process with something
> based on make-process, this is a big difference...

More like forewarned. Do we want to exchange 25% of performance for 
extra reactivity? We might. But we'd probably put that behind a pref and 
have to maintain two implementations.

> There's zero reason it has to be so slow... maybe I should try to make a
> better make-process API and implementation which is actually fast.
> (without worrying about being constrained by compatibility with
> something that's already dog-slow)

I don't know if the API itself is at fault. The first step should be to 
investigate which part of the current one is actually slow, I think.

But then, of course, if improved performance really requires a change in 
the API, we can switch to some new one too (which having to maintain at 
least two implementations for a number of years).

BTW, looking at the difference between the with-find-* approaches' 
performance, it seems like most of it comes down to GC.

Any chance we're doing extra copying of strings even when we don't have 
to, or some inefficient copying -- compared to the sync implementation? 
E.g. we could use the "fast" approach at least when the :filter is not 
specified (which is the case in the first impl, "with-find"). The manual 
says this:

  The default filter simply outputs directly to the process buffer.

Perhaps it's worth looking at.