Re: [PATCH] ref-filter: handle nested tags in --points-at option

["Jan Klötzke" <jan@kloetzke.net>]

Am Sun, Jul 02, 2023 at 06:02:43PM -0400 schrieb Jeff King:
> On Sun, Jul 02, 2023 at 08:56:11AM -0400, Jeff King wrote:
> 
> > My biggest question would be whether this introduces any performance
> > penalty for the more common cases (lightweight tags and single-level
> > annotated tags). The answer is "no", I think; we are already paying the
> > cost to parse every object to find out if it's a tag, and your new loop
> > only does an extra parse if we see a tag-of-tag. Good.
> 
> Reading more carefully, I think this does actually change the
> performance a bit, because we end up parsing the pointed-to commits, as
> well. So here's before and after your patch running "git for-each-ref
> --points-at=HEAD" on linux.git (785 refs, all but 3 are tags):
> 
>   Benchmark 1: ./git.old for-each-ref --points-at=HEAD
>     Time (mean ± σ):      11.4 ms ±   0.2 ms    [User: 6.5 ms, System: 4.9 ms]
>     Range (min … max):    11.0 ms …  12.3 ms    239 runs
>   
>   Benchmark 2: ./git.new for-each-ref --points-at=HEAD
>     Time (mean ± σ):      20.6 ms ±   0.5 ms    [User: 10.4 ms, System: 10.2 ms]
>     Range (min … max):    19.8 ms …  22.7 ms    133 runs
>   
>   Summary
>     './git.old for-each-ref --points-at=HEAD' ran
>       1.80 ± 0.06 times faster than './git.new for-each-ref --points-at=HEAD'
> 
> The absolute numbers are pretty small, but the percent change isn't
> great. I'll send some patches in a minute that can be applied on top to
> improve this case, as well as fix the other issues I pointed out in the
> existing code.

I have to admit I was not entirely sure about the performance
implications. The relative performance drop is indeed substantial.
Thanks for the thorough review and swiftly taking care of these!

-- Jan