GNU bug report logs -
#64735
29.0.92; find invocations are ~15x slower because of ignores
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On 11/09/2023 14:57, Eli Zaretskii wrote:
>> Date: Mon, 11 Sep 2023 03:02:55 +0300
>> Cc: luangruo <at> yahoo.com, sbaugh <at> janestreet.com, yantar92 <at> posteo.net,
>> 64735 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>>> You could record its value in a local variable at the entry to
>>> garbage_collect, and the expose that value to Lisp.
>>
>> That also doesn't seem to give much, given that the condition for
>> entering 'maybe_garbage_collect' is (consing_until_gc < 0). I.e. we wait
>> until it's down to 0, then garbage-collect.
>
> 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.
>> What's in there? First of all, for find-directory-files-recursively-3,
>> there are 0 garbage collections between the beginning of the function
>> and when we start parsing the output (no GCs while the process is
>> writing to the buffer synchronously). I guess inserting output in a
>> buffer doesn't increase consing, so there's nothing to GC?
>
> No, we just don't count increasing size of buffer text in the "consing
> since GC" counter. Basically, buffer text is never "garbage", except
> when a buffer is killed.
That makes sense. Perhaps it hints at a faster design for calling
process asynchronously as well (more on another experiment later).
>> Next: for find-directory-files-recursively-2, the process only finishes
>> at the end, when all GC cycles are done for. I suppose that also means
>> we block the process's output while Lisp is running, and also that
>> whatever GC events occur might coincide with the chunks of output coming
>> from the process, and however many of them turn out to be in total.
>
> We don't block the process when GC runs. We do stop reading from the
> process, so if and when the pipe fills, the OS will block the process.
Right. But the effect is almost the same, including the potential
side-effect that (IIUC) when a process is waiting like that, it's just
suspended and not rushing ahead using the CPU/disk/etc resources to the
max. That's an orthogonal train of thought, sorry.
[gcs2b.txt (text/plain, attachment)]
[gcs3b.txt (text/plain, attachment)]
This bug report was last modified 1 year and 274 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.