On Sat, 8 Dec 2007, Junio C Hamano wrote:

quoted text
> Nicolas Pitre <nico@cam.org> writes:
> 
> > On Fri, 7 Dec 2007, Jon Smirl wrote:
> >
> >> Starting with a 2GB pack of the same data my process size only grew to
> >> 3GB with 2GB of mmaps.
> >
> > Which is quite reasonable, even if the same issue might still be there.
> >
> > So the problem seems to be related to the pack access code and not the 
> > repack code.  And it must have something to do with the number of deltas 
> > being replayed.  And because the repack is attempting delta compression 
> > roughly from newest to oldest, and because old objects are typically in 
> > a deeper delta chain, then this might explain the logarithmic slowdown.
> >
> > So something must be wrong with the delta cache in sha1_file.c somehow.
> 
> I was reaching the same conclusion but haven't managed to spot anything
> blatantly wrong in that area.  Will need to dig more.

I didn't find anything wrong there either. I'll have to run some more 
gcc repacking tests myself, despite not having a blazingly fast machine 
making for rather long turnarounds.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html