Re: [PATCH] Make git-pack-redundant non-horribly slow on large sets of packs

From: Alex Riesen <raa.lkml@gmail.com>
Date: Nov 17, 2005, 20:39 UTC
Message-ID: <20051117203915.GB3013@steel.home>
In-Reply-To: <81b0412b0511162345g1483e7cfia768b18ba3eb1db@mail.gmail.com>

Lukas Sandström, Thu, Nov 17, 2005 14:11:56 +0100:

> Change the smallest-set detection algortithm so that when
> we have found a good set, we don't check any larger sets.

I used latest git (a575603af20a795584d79b32c30bda10fcae5d3f Merge branch 'tojunio' of http://locke.catalyst.net.nz/git/git-martinlanghoff) and the patch on top.

Alex Riesen, Thu, Nov 17, 2005 08:45:46 +0100:

Show 7 quoted lines

> > Could you try updating to the latest snapshot? There was a bug in a
> > list handling function which was fixed recently, perhaps your problem
> > is related.
> 
> will try, but I didn't realize yesterday that it might be a good idea
> to keep the old repository around. The lot of packs was automatically
> created by incremental repacking after every pull. Sorry...

ok, pack-redundant --all in a repository with 25 packs completed in 1.346 sec. That's definitely an improvement.

But, the repository (a clone of Linus' kernel) didn't have a superpack. I created one (git repack -a) and started "pack-redundant --all". And almost oomed the system (it has 1Gb RAM + 512Mb(historically) swap, BTW): oom-killer killed git-pack-redundant. Peak memory usage was around 1.3Gb, than everything stopped. The repository had 140718 objects.