GNU bug report logs -
#64735
29.0.92; find invocations are ~15x slower because of ignores
Previous Next
Full log
Message #365 received at 64735 <at> debbugs.gnu.org (full text, mbox):
> 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 12:57:53 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> > 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.
>
> Thanks for the clarification!
> Then, would it make sense to have such a callback API more general? (not
> just for listing directory files).
>
> For example, the callbacks might be attached to a list variable that
> will accumulate the async results. Then, the callbacks will be called on
> that list, similar to how process sentinels are called when a chunk of
> output is arriving to the process buffer.
Anything's possible, but when a function produces text, like file
names, then the natural thing is either to return them as strings or
to insert them into some buffer.
This bug report was last modified 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.