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

Karthik Nayak <[email protected]> Sun, 23 Aug 2026 13:39:48 -0400
Newsgroups	org.kernel.vger.git
Message-ID	<CAOLa=ZQpeCKzQ3EVXQEhfxL1khUH0YD6_Kc1qDQhxoN926rsBw@mail.gmail.com>
Jeff King <[email protected]> writes:

> 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

I can reproduce your results locally too. I was a bit stumbled why,
I was using a modified version of our benchmarks repository [1], which
was using a fixed static target.

The difference was I was updating 'refs/heads/*' and your script does
'refs/tags/*'. The difference is in `should_write_log()`, where for
LOG_REFS_NORMAL and 'refs/heads/*' we shortcut to creating the logs.
While for tags, we do a check to see reflog already exists. This causes
a stack reload (before my patches). This shows the significant
difference in our benchmarks.

Funnily, I use 'refs/tags/*' for strace, so you do see the diff there.
Will modify my commit message to reflect the benchmark :)

[1]: https://gitlab.com/gitlab-org/data-access/git/benchmarks/
signature.asc (application/pgp-signature, 690 B)