Re: [PATCH v2 2/2] blame: enable and test the sparse index

[Elijah Newren <newren@gmail.com>]

On Tue, Oct 26, 2021 at 9:17 AM Lessley Dennington
<lessleydennington@gmail.com> wrote:
>
> On 10/25/21 1:53 PM, Taylor Blau wrote:
> > On Fri, Oct 15, 2021 at 09:20:35PM +0000, Lessley Dennington via GitGitGadget wrote:
> >> From: Lessley Dennington <lessleydennington@gmail.com>
> >>
> >> Enable the sparse index for the 'git blame' command. The index was already
> >> not expanded with this command, so the most interesting thing to do is to
> >> add tests that verify that 'git blame' behaves correctly when the sparse
> >> index is enabled and that its performance improves. More specifically, these
> >> cases are:
> >>
> >> 1. The index is not expanded for 'blame' when given paths in the sparse
> >> checkout cone at multiple levels.
> >>
> >> 2. Performance measurably improves for 'blame' with sparse index when given
> >> paths in the sparse checkout cone at multiple levels.
> >>
> >> The `p2000` tests demonstrate a ~60% execution time reduction when running
> >> 'blame' for a file two levels deep and and a ~30% execution time reduction
> >> for a file three levels deep.
> >
> > Eek. What's eating up the other 30% when we have to open up another
> > layer of trees?
> >
> I'm not sure to be totally honest. However, given these are both pretty
> good time reductions I don't think we should be terribly concerned.

It's not something eating up more time in the sparse-index code; let's
look a bit closer...

> >>
> >> Test                                         before  after
> >> ----------------------------------------------------------------
> >> 2000.62: git blame f2/f4/a (full-v3)         0.31    0.32 +3.2%
> >> 2000.63: git blame f2/f4/a (full-v4)         0.29    0.31 +6.9%
> >> 2000.64: git blame f2/f4/a (sparse-v3)       0.55    0.23 -58.2%
> >> 2000.65: git blame f2/f4/a (sparse-v4)       0.57    0.23 -59.6%
> >> 2000.66: git blame f2/f4/f3/a (full-v3)      0.77    0.85 +10.4%
> >> 2000.67: git blame f2/f4/f3/a (full-v4)      0.78    0.81 +3.8%
> >> 2000.68: git blame f2/f4/f3/a (sparse-v3)    1.07    0.72 -32.7%
> >> 2000.99: git blame f2/f4/f3/a (sparse-v4)    1.05    0.73 -30.5%

Time was ~0.55s for the full at two levels deep, and dropped by just
over 0.3s in sparse-index.
Time was ~1.05s for the full at three levels deep, and dropped by just
over 0.3s in sparse-index.

So, the sparse-index enabling saves us the same amount of time, it's
just that the overall execution time for the non-sparse-index
comparison point goes up.  Saving the same amount of time for the two
cases seems intuitive to me; both cases get to avoid looking at the
same number of index entries outside the sparsity paths.