GNU bug report logs -
#64735
29.0.92; find invocations are ~15x slower because of ignores
Previous Next
Full log
Message #389 received at 64735 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 23 Jul 2023 22:07:17 +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>
>
> On 23/07/2023 21:21, Eli Zaretskii wrote:
> >> Date: Sun, 23 Jul 2023 20:58:24 +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>
> >>
> >> A possible advantage of doing it earlier, is that if filtering happens
> >> in C code you could do it before allocating Lisp strings
> >
> > That's not what happens today. And it isn't easy to do what you
> > suggest, since the file names we get from the C APIs need to be
> > decoded, and that is awkward at best with C strings.
>
> It is what happens today when 'find' is used, though.
No, I was talking about what file-name-all-completions does.
> Far be it from me to insist, though, but if we indeed reimplemented all
> the good parts of 'find', that would make the new function a suitable
> replacement/improvement, at least on local hosts (instead of it just
> being used as a fallback).
The basic problem here is this: the regexp or pattern to filter out
ignorables is specified as a Lisp string, which is in the internal
Emacs representation of characters. So to compare file names we
receive either from Find or from a C API, we need either to decode the
file names we receive (which in practice means they should be Lisp
strings), or encode the regexp and use its C string payload.
This bug report was last modified 1 year and 273 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.