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
On 23/07/2023 20:56, Eli Zaretskii wrote:
>> Date: Sun, 23 Jul 2023 20:46:19 +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 14:18, Eli Zaretskii wrote:
>>>> Date: Sun, 23 Jul 2023 13:46:30 +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 08:11, Eli Zaretskii wrote:
>>>>> Even better: compute completion-regexp-list so that IGNOREs are
>>>>> filtered by file-name-all-completions in the first place.
>>>> We don't have lookahead in Emacs regexps, so I'm not sure it's possible
>>>> to construct regexp that says "don't match entries A, B and C".
>>> Well, maybe just having a way of telling file-name-all-completions to
>>> negate the sense of completion-regexp-list would be enough to make
>>> that happen?
>>
>> Some way to do that is certainly possible (e.g. a new option and
>> corresponding code, maybe; maybe not), it's just that the person
>> implementing it should consider the performance of the resulting solution.
>
> I agree. However, if we are going to implement filtering of file
> names, I don't think it matters where in the pipeline to perform the
> filtering.
A possible advantage of doing it earlier, is that if filtering happens
in C code you could do it before allocating Lisp strings, thereby
lowering the resulting GC pressure at the outset.
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.