Subject: Re: bug#66806: 30.0.50; [PATCH] 'project-find-regexp' passes Git submodules to the search program
From: Dmitry Gutov <[email-masked]>
To: Jim Porter <[email-masked]>, [email-masked]
Date: Mon, 30 Oct 2023 04:00:51 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Version: 30.1

On 30/10/2023 02:58, Jim Porter wrote:
> On 10/29/2023 2:41 PM, Dmitry Gutov wrote:
>> And that's not to mention usage over Tramp (which would be affected by 
>> the +1 process call that you mentioned as well, but that seems 
>> unavoidable).
> 
> Yeah, I don't see a way around that, unless we constructed a complex 
> command to run via Tramp that does it all in one go.
> 
> (I looked into using the "--stage" argument for "git ls-files", which 
> gets most of the way to fixing this, but you could break that logic with 
> evil file names not in the tree...)

Filtering out gitlinks based on the mode bits? Clever.

Would probably slow down the parsing of the output, though. Not sure by 
how much.

>> Anyway, after recent experience micro-optimizing list operations, I 
>> came up with this version where the impact seems minimal.
>>
>> WDYT?
> 
> Thanks, that helped form the basis for the attached patch. It moves the 
> 'member' call into the lambda for the original 'mapcar', and then we can 
> just 'delq' all the nil elements. Benchmarking against the Emacs repo, 
> this still seems to have a minimal perf impact.

Ah, nice. delq is pretty handy to abbreviate the relinking.

We could combine both steps to eliminate an extra list altogether, but 
that only yields a further 2-3% improvement. Maybe later.

> There might also be a benefit to using "git ls-files 
> --recurse-submodules" when we can (i.e. when not using "-o"), but maybe 
> we can leave that optimization for another day.

As long as it doesn't result in too much code duplication.

Anyway, I've pushed your latest patch. Thanks! And closing.