On 6/22/2026 5:03 PM, Kristofer Karlsson wrote:

On Mon, 22 Jun 2026 at 22:26, Derrick Stolee [off-list ref] wrote:

quoted

I've used hyperfine [1] when doing specific performance tests
in the past. You can build Git before and after and have hyperfine
run the two modes and compare them:

        hyperfine --warmup=3 \
                -n 'old' "~/git-old/bin-wrappers/git -C $repo merge-base $A $B" \
                -n 'new' "~/git-new/bin-wrappers/git -C $repo merge-base $A $B"

[1] https://github.com/sharkdp/hyperfine

I can definitely use that, but I was thinking that the overhead
of operations such as repo_parse_commit would be high relative
to the overhead of the new paint_queue struct such that it would
be hard to properly measure and that it would be easier if I could
spread out that cost across multiple internal runs (which requires
a custom binary of some sort), but perhaps it's enough to just
show that there's no measurable regression here and then
hyperfine is indeed the right fit. I'll start with that and see if I need
to do anything more complex.

Unit-level performance is nice, but doesn't tell the whole story.

We typically focus on end-to-end performance numbers when possible.

Another way to do it would be to use trace2_region_enter() and
trace2_region_leave() markers and then pull the timing data out of
the trace2 event logs. It's more complicated and usually only
needed if we are struggling to reproduce the performance impact due
to external factors.

Thanks,
-Stolee