On Sat, Apr 3, 2010 at 17:23, Frans Pop <elendil@xxxxxxxxx> wrote:
> On Saturday 03 April 2010, Michael Witten wrote:
>> On Fri, Apr 2, 2010 at 16:05, Frans Pop <elendil@xxxxxxxxx> wrote:
>> > I haven't had the patience to let it finish
> ...
> I've tried it today on my linux-2.6 repo as well and the same thing
> happened. At first the progress is not fast but reasonable. When it gets
> to about 45% percent it starts slowing down a lot: from ~1500 objects per
> update of the counters to ~300 objects per update. And who knows what
> the progress is going to be when it reaches 70% or 90%: 10 per update?
>
> With a total of over 2 milion objects in the repository such a low speed is
> simply not going to work, ever. So I maintain that it is effectively
> unusable.
Well, all I can do is quote myself:
Last time I used this option (on Linus's Linux repo),
I let the algorithm do its thing for a couple of hours.
Maybe the efficiency could be vastly improved, but
it does finish if you let it.
On Fri, Apr 2, 2010 at 16:12, Frans Pop <elendil@xxxxxxxxx> wrote:
> I'm seeing this with both git 1.6.6.1 and 1.7.0.3 on the same repo.
I think I must have run gc with 1.7.0.2.199.g90a2bf9; perhaps you
could use something like oprofile to figure out where gc is spending
most of its time.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html