Re: [PATCH 3/3] reftable/stack: avoid reloading the stack when already locked

[Jeff King <peff@peff.net>]

On Wed, Aug 19, 2026 at 03:19:39PM +0200, Karthik Nayak wrote:

> Benchmarking with a fixed, non-symbolic target OID shows a modest but
> consistent ~1-2% improvement in clock time for `update-ref` across ref
> counts ranging from 2,000 to 100,000.

Interesting. I get ~25% speedup with this patch, doing this:

  git init --ref-format=reftable
  cp -a .git/reftable reftable.orig
  seq -f "create refs/tags/foo-%g $blob" 50000 >input
  hyperfine -p 'rm -rf .git/reftable; cp -a reftable.orig .git/reftable' \
           -L v old,new \
	   './git.{v} update-ref --stdin <input'

(where git.old and git.new are builds before and after your series).
With 50,000 refs I get:

  Benchmark 1: ./git.old update-ref --stdin <input
    Time (mean ± σ):     125.8 ms ±   4.4 ms    [User: 91.2 ms, System: 34.5 ms]
    Range (min … max):   121.0 ms … 135.2 ms    21 runs
  
  Benchmark 2: ./git.new update-ref --stdin <input
    Time (mean ± σ):     100.4 ms ±   3.1 ms    [User: 90.9 ms, System: 9.4 ms]
    Range (min … max):    95.0 ms … 106.0 ms    29 runs
  
  Summary
    ./git.new update-ref --stdin <input ran
      1.25 ± 0.06 times faster than ./git.old update-ref --stdin <input

And it seems to scale down linearly. With 10,000 it's:

  Benchmark 1: ./git.old update-ref --stdin <input
    Time (mean ± σ):      24.2 ms ±   1.4 ms    [User: 17.1 ms, System: 7.1 ms]
    Range (min … max):    22.6 ms …  32.8 ms    83 runs
  
  Benchmark 2: ./git.new update-ref --stdin <input
    Time (mean ± σ):      19.2 ms ±   1.0 ms    [User: 16.9 ms, System: 2.4 ms]
    Range (min … max):    17.9 ms …  25.8 ms    135 runs
  
  Summary
    ./git.new update-ref --stdin <input ran
      1.26 ± 0.10 times faster than ./git.old update-ref --stdin <input

So 1/5 as much work took 1/5 as much time, but we still saved 25% of the
relative time with the patch.

I'm a little curious why we such get different numbers, but it may not
be worth digging too deep. Avoiding unnecessary syscalls seems worth it
to me regardless, as they can sometimes be more expensive you expect
(say, on a networked filesystem).

-Peff