GNU bug report logs - #64735
29.0.92; find invocations are ~15x slower because of ignores

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Wed, 19 Jul 2023 21:17:02 UTC

Severity: normal

Found in version 29.0.92

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: sbaugh <at> janestreet.com, rms <at> gnu.org, sbaugh <at> catern.com, dmitry <at> gutov.dev, michael.albinus <at> gmx.de, 64735 <at> debbugs.gnu.org
Subject: bug#64735: 29.0.92; find invocations are ~15x slower because of ignores
Date: Sun, 23 Jul 2023 15:49:48 +0300
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: sbaugh <at> catern.com, sbaugh <at> janestreet.com, dmitry <at> gutov.dev,
>  michael.albinus <at> gmx.de, rms <at> gnu.org, 64735 <at> debbugs.gnu.org
> Date: Sun, 23 Jul 2023 11:43:22 +0000
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> But what is the strategy that should be used to call the CALLBACK?
> >> You clearly had something other than "call as soon as we got another
> >> file name" in mind.
> >
> > It could be "call as soon as we got 100 file names", for example.  The
> > number can even be a separate parameter passed to the API.
> 
> Will consing the filename strings also be delayed until the callback is invoked?

No.  I don't think it's possible (or desirable).  We could keep them
in some malloc'ed buffer, of course, but what's the point?  This would
only be justified if somehow creation of Lisp strings proved to be a
terrible bottleneck, which would leave me mightily surprised.




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.