Re: "git reflog expire --all" very slow

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> ...
>> This if anything makes things just go slower.
>> 
>> Not much, but some. It went from 36.566s to 38.070s. That may be in the 
>> noise, I've not done any sensitivity analysis.
>
> I actually think that the cutoff for history traversal is bogus.  You may
> have a 30-day old reflog entry that pulled in a 45-day old commit, and
> giving up the smudging at the expiry cutoff timestamp does not make much
> sense.
>
> I do have a lot of reflog entries kept around, as my main repository has
> these:
>
>         [gc]
>                 reflogexpire = '2005-01-01 00:00:00 +0000'
>                 reflogexpireunreachable = '2005-01-01 00:00:00 +0000'
>
> so let me experiment a bit more.

To initially prune a copy of my git repository that was never pruned
before, it takes a lot of time with or without the patch to prune from the
original 73476 reflog entries.

(without patch)
23.46user 0.23system 0:23.70elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+5464outputs (0major+6045minor)pagefaults 0swaps

(with patch, but with a bit of fprintf's for counting)
21.99user 0.40system 0:22.56elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+5472outputs (0major+6040minor)pagefaults 0swaps

After the initial pruning, with 13780 reflog entries still left (and no
further pruning expected), I am seeing these:

(without patch)
2.09user 0.22system 0:02.32elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+5464outputs (0major+4956minor)pagefaults 0swaps

(with patch, but again with a bit of fprintf's for counting)
0.76user 0.25system 0:01.05elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+5464outputs (0major+4918minor)pagefaults 0swaps

I might be better off traversing down all the way and do away with
in_merge_bases(), but that might hold true only for something small like
git.git and the kernel.