Re: [PATCH 2/2] line-log: avoid unnecessary full tree diffs

["SZEDER Gábor" <szeder.dev@gmail.com>]

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.