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

[Eli Zaretskii]

> Date: Tue, 12 Sep 2023 02:06:50 +0300
> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, yantar92@posteo.net,
>  64735@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > No, we don't wait until it's zero, we perform GC on the first
> > opportunity that we _notice_ that it crossed zero.  So examining how
> > negative is the value of consing_until_gc when GC is actually
> > performed could tell us whether we checked the threshold with high
> > enough frequency, and comparing these values between different runs
> > could tell us whether the shorter time spend in GC means really less
> > garbage or less frequent checks for the need to GC.
> 
> Good point, I'm attaching the same outputs with "last value of 
> consing_until_gc" added to every line.
> 
> There are some pretty low values in the "read-process-output-max 409600" 
> part of the experiment, which probably means runtime staying in C 
> accumulating the output into the (now larger) buffer? Not sure.

No, I think this means we really miss some GC opportunities, and we
cons quite a lot more strings between GC cycles due to that.  I guess
this happens because we somehow cons many strings in code that doesn't
call maybe_gc or something.