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

Junio C Hamano [off-list ref] writes:

Linus Torvalds [off-list ref] writes:

quoted

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