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

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Aug 23, 2019, 10:04 UTC
Message-ID: <20190823100446.GI20404@szeder.dev>
In-Reply-To: <20190822084158.GC20404@szeder.dev>

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

Show 15 quoted lines

>   # 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.