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

[Dmitry Gutov <dmitry@gutov.dev>]

On 14/09/2023 08:41, Eli Zaretskii wrote:
>> Date: Wed, 13 Sep 2023 23:38:29 +0300
>> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net,
>>   64735@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>> I think these questions are slightly premature.  We should first have
>>> the implementation of that filter, and then look for candidates that
>>> could benefit from it.
>>
>> The implementation in that patch looks almost complete to me, unless you
>> have any further comments.
> 
> Fine, then please post a complete patch with all the bells and
> whistles, and let's have it reviewed more widely.  (I suggest a new
> bug report, as this one is already prohibitively long to follow,
> includes unrelated issues, and I fear some people will ignore patches
> posted to it).  I think there are a few subtleties we still need to
> figure out.

Sure, filed bug#66020.

>    If FILTER is the symbol ‘buffer’, it works like the default filter,
>    but makes some shortcuts to be faster: it doesn't adjust markers and
>    the process mark (something else?).
> 
> Of course, the real text will depend on what the final patch will look
> like: I'm not yet sure I understand which parts of
> internal-default-process-filter you want to keep in this alternative
> filter.  (If you intend to keep all of them, it might be better to
> replace internal-default-process-filter completely, perhaps first with
> some variable exposed to Lisp which we could use to see if the new one
> causes issues.)

Very good. And thanks for pointing out the omissions, so I went with 
reusing parts of internal-default-process-filter.

>>>> I'm not sure what negatives to test for, though. Raising the limit 10x
>>>> is unlikely to lead to an OOM, but I guess some processes could grow
>>>> higher latency?..
>>>
>>> With a large buffer and small subprocess output we will ask the OS for
>>> a large memory increment for no good reason.  Then the following GC
>>> will want to compact the gap, which means it will be slower.
>>
>> I wonder what scenario that might become apparent in. Launching many
>> small processes at once? Can't think of a realistic test case.
> 
> One process suffices.  The effect might not be significant, but
> slowdowns due to new features are generally considered regressions.

We'd need some objective way to evaluate this. Otherwise we'd just stop 
at the prospect of slowing down some process somewhere by 9ns (never 
mind speeding others up).