On Thu, Aug 22, 2019 at 10:41:58AM +0200, SZEDER Gábor wrote:
> On Wed, Aug 21, 2019 at 07:35:15PM +0200, SZEDER Gábor wrote:
> Subject: [PATCH 3/2] WIP line-log: stop diff-ing after first TREESAME merge parent
> # linux.git, ~7% of all commits are merges
> $ time ~/src/git/git --no-pager log \
> -L:build_restore_work_registers:arch/mips/mm/tlbex.c v5.2
>
> Before:
>
> real 0m2.599s
> user 0m2.466s
> sys 0m0.157s
>
> After:
>
> real 0m1.976s
> user 0m1.856s
> sys 0m0.121s
So, to recap, the above command follows the given line range through
the whole history, and the timings were done with these three patches
on top of v2.23.0 and with a commit-graph file present and used.
When merged with my more responsive line-level log series, the same
command takes about 12% longer:
real 0m2.216s
user 0m2.108s
sys 0m0.109s
Looking at the flame graphs generated from the perf profiles I notice
the following:
- (line_log_)process_ranges_arbitrary_commit(), i.e. the function
responsible for processing all commits for the line-level log,
shows up in 2408 samples before the merge and in 2387 samples
after the merge. I'm inclined to write it off as noise.
- Before the merge limit_list() and sort_in_topological_order(), the
two functions responsible for topo-ordering without generation
numbers, show up in 2484 and 707 samples, respectively, which is
3191 samples combined.
- After the merge expand_topo_walk() alone shows up in 4341 samples,
with next_topo_commit() in 72 samples.
So it appears that the generation numbers-based topo-ordering is
almost 40% slower than "traditional" topo-ordering. It came as a
surprise to me, but perhaps to you it's expected?
Anyway, the time to show the first commit is still much better with
generarion numbers, so overall I think it more than offsets this ~10%
difference.
