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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2009, 05:50 UTC
Message-ID: <7vr60e6y1v.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vy6um6z9m.fsf@gitster.siamese.dyndns.org>

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

Show 20 quoted lines

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