Re: Performance regression in "update" hooks

[Adrian Ratiu <adrian.ratiu@collabora.com>]

On Mon, 02 Mar 2026, Adrian Ratiu <adrian.ratiu@collabora.com> wrote:
> On Mon, 02 Mar 2026, Patrick Steinhardt <ps@pks.im> wrote:
>> Hi,
>>
>> Bencher has alerted me that there's been two performance regressions in
>> git-receive-pack(1) [1] and git-fetch(1) [2].
>>
>> The first one is quite easy to reproduce with the benchmarks at [3] and
>> bisects to fc148b146a (receive-pack: convert update hooks to new API,
>> 2026-01-28):
>>
>>   $ cd receive-refs
>>   $ ./run --revisions /path/to/your/git/repo \
>>       fc148b146ad41be71a7852c4867f0773cbfe1ff9~,fc148b146ad41be71a7852c4867f0773cbfe1ff9 \
>>       --parameter-list refformat reftable \
>>       --parameter-list refcount 10000
>>
>>   Benchmark 1: receive: many refs (refformat = reftable, refcount = 10000, revision = fc148b146ad41be71a7852c4867f0773cbfe1ff9~)
>>     Time (mean ± σ):     182.0 ms ±   2.7 ms    [User: 91.5 ms, System: 89.3 ms]
>>     Range (min … max):   175.8 ms … 185.0 ms    15 runs
>>
>>   Benchmark 2: receive: many refs (refformat = reftable, refcount = 10000, revision = fc148b146ad41be71a7852c4867f0773cbfe1ff9)
>>     Time (mean ± σ):     484.6 ms ±  27.6 ms    [User: 176.2 ms, System: 376.1 ms]
>>     Range (min … max):   406.2 ms … 495.1 ms    10 runs
>>
>>   Summary
>>     receive: many refs (refformat = reftable, refcount = 10000, revision = fc148b146ad41be71a7852c4867f0773cbfe1ff9~) ran
>>       2.66 ± 0.16 times faster than receive: many refs (refformat = reftable, refcount = 10000, revision = fc148b146ad41be71a7852c4867f0773cbfe1ff9)
>>
>> I've Cc'd Adrian.
>
> Hi Patrick,
>
> I looked at the commits before and after the many-refs test regression
> and it appears the regressions started after Junio landed v2 of the
> config series in next [1], which might cause it.
>
> v2 was not ready to land. I sent v3 yesterday addressing all the
> feedback, didn't even realize v2 landed. :)
>
> Does the regression go away if you revert [1] ?
>
> I don't have the benchmark setup and it might be easier for you to
> confirm?
>
> Many thanks!
>
> 1:
>
> commit 6a04cca28e210f0c51cfefcb52475c7ede6e99fb
> Merge: d6ebc97cb1 4b12cd3ae3
> Author:     Junio C Hamano <gitster@pobox.com>
> AuthorDate: Fri Feb 27 15:16:30 2026 -0800
> Commit:     Junio C Hamano <gitster@pobox.com>
> CommitDate: Fri Feb 27 15:16:30 2026 -0800
>
>     Merge branch 'ar/config-hooks' into next
>     
>     Allow hook commands to be defined (possibly centrally) in the
>     configuration files, and run multiple of them for the same hook
>     event.
>     
>     * ar/config-hooks:
>       hook: add -z option to "git hook list"
>       hook: allow out-of-repo 'git hook' invocations
>       hook: allow event = "" to overwrite previous values
>       hook: allow disabling config hooks
>       hook: include hooks from the config
>       hook: add "git hook list" command
>       hook: run a list of hooks to prepare for multihook support
>       hook: add internal state alloc/free callbacks

Actually I think these are two separate issues.

I will reproduce and look into the regression which bisected to
c148b146a (receive-pack: convert update hooks to new API,  2026-01-28).