On Sat, 8 Dec 2007, Junio C Hamano wrote: > Nicolas Pitre <nico@xxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
