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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, sbaugh <at> janestreet.com, yantar92 <at> posteo.net, 64735 <at> debbugs.gnu.org
Subject: bug#64735: 29.0.92; find invocations are ~15x slower because of ignores
Date: Sun, 10 Sep 2023 04:30:24 +0300

On 08/09/2023 09:35, Eli Zaretskii wrote:
>>> These questions can only be answered by dumping the values of the 2 GC
>>> thresholds and of consing_until_gc for each GC cycle.  It could be
>>> that we are consing more Lisp memory, or it could be that one of the
>>> implementations provides fewer opportunities for Emacs to call
>>> maybe_gc.  Or it could be some combination of the two.
>> Do you think the outputs of
>> https://elpa.gnu.org/packages/emacs-gc-stats.html  could help?
> I think you'd need to expose consing_until_gc to Lisp, and then you
> can collect the data from Lisp.

I can expose it to Lisp and print all three from post-gc-hook, but the 
result just looks like this:

gc-pct 0.1 gc-thr 800000 cugc 4611686018427387903

Perhaps I need to add a hook which runs at the beginning of GC? Or of 
maybe_gc even?

Alternatively, (memory-use-counts) seems to retain some counters which 
don't get erased during garbage collection.

>> All examples which use make-process call it with :connection-type 'pipe.
>>
>> The one that calls process-file (the "synchronous" impl) also probably
>> does, but I don't see that in the docstring.
> Yes, call-process uses pipes.  So finding the optimum boils down to
> running various scenarios.  It is also possible that the optimum will
> be different on different systems, btw.

Sure, but I'd like to improve the state of affairs in at least the main one.

And as for MS Windows, IIRC all find-based solution are currently slow 
equally, so we're unlikely to make things worse there anyway.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.