aboutsummaryrefslogtreecommitdiffstats
path: root/builtin/commit.c
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2024-03-04 11:49:18 +0100
committerJunio C Hamano <gitster@pobox.com>2024-03-04 10:19:40 -0800
commit080f8c4565609dab2969587d1f8f11e960d0af34 (patch)
treed37c1ef79cd7082048654e902ebe77ff8cd8f76a /builtin/commit.c
parentreftable/merged: circumvent pqueue with single subiter (diff)
downloadgit-080f8c4565609dab2969587d1f8f11e960d0af34.tar.gz
git-080f8c4565609dab2969587d1f8f11e960d0af34.zip
reftable/merged: avoid duplicate pqueue emptiness check
When calling `merged_iter_next_void()` we first check whether the iter has been exhausted already. We already perform this check two levels down the stack in `merged_iter_next_entry()` though, which makes this check redundant. Now if this check was there to accelerate the common case it might have made sense to keep it. But the iterator being exhausted is rather the uncommon case because you can expect most reftable stacks to contain more than two refs. Simplify the code by removing the check. As `merged_iter_next_void()` is basically empty except for calling `merged_iter_next()` now, merge these two functions. This also results in a tiny speedup when iterating over many refs: Benchmark 1: show-ref: single matching ref (revision = HEAD~) Time (mean ± σ): 125.6 ms ± 3.8 ms [User: 122.7 ms, System: 2.8 ms] Range (min … max): 122.4 ms … 153.4 ms 1000 runs Benchmark 2: show-ref: single matching ref (revision = HEAD) Time (mean ± σ): 124.0 ms ± 3.9 ms [User: 121.1 ms, System: 2.8 ms] Range (min … max): 120.1 ms … 156.4 ms 1000 runs Summary show-ref: single matching ref (revision = HEAD) ran 1.01 ± 0.04 times faster than show-ref: single matching ref (revision = HEAD~) Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/commit.c')
0 files changed, 0 insertions, 0 deletions