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

From: Jeff King <peff@peff.net>
Date: Jul 2, 2023, 22:02 UTC
Message-ID: <20230702220243.GA1534980@coredump.intra.peff.net>
In-Reply-To: <20230702125611.GA1036686@coredump.intra.peff.net>

On Sun, Jul 02, 2023 at 08:56:11AM -0400, Jeff King wrote:

Show 5 quoted lines

> 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.

-Peff