On Tue, Oct 26, 2021 at 9:17 AM Lessley Dennington <lessleydennington@xxxxxxxxx> 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@xxxxxxxxx> > >> > >> 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.
