Re: Performance issue: initial git clone causes massive repack

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.04.23 10:01:46 +1200, Sam Vilain wrote:
> Nicolas Pitre wrote:
> >> Now that the GSoC projects have been announced I can give you the good
> >> news that one of our two projects is to optimise this stage in
> >> git-daemon; I'm hoping we can get it down to being almost as cheap as
> >> the workaround you described in your post. I'll certainly be using your
> >> repository as a test case :-)
> >
> > Please keep me in the loop as much as possible. I'd prefer we're not in
> > disagreement over the implementation only after final patches are posted
> > to the list.
> 
> Thanks Nico, given your close working knowledge of the pack-objects
> code this will be very much appreciated. Perhaps you can first help
> out by telling me what you have to say about moving object enumeration
> from upload-pack to pack-objects?

Here's a bit about that:
http://article.gmane.org/gmane.comp.version-control.git/116032

Note that my RSS measurement should be invalid by now. Linus's
patches(*) should have improved the memory usage for that scenario by
quite a bit, since we used to keep a lot of the stuff that the revision
enumeration required in memory, even after that processed finished,
which should no longer be the case IIRC. And the peak memory usage for
that process was also improved on its own, as the whole buffering is
gone.

Björn

(*) These commits:
8d2dfc49b1     process_{tree,blob}: show objects without buffering
cf2ab916af     show_object(): push path_name() call further down
213152688c     process_{tree,blob}: Remove useless xstrdup calls