From: Jon Smirl Date: Sun, 09 Dec 2007 15:19:23 GMT Subject: Re: Something is broken in repack Message-ID: <9e4733910712090719g713972a9p1c18bc149dc0237c@mail.gmail.com> In-Reply-To: <7vprxgs36w.fsf@gitster.siamese.dyndns.org> On 12/9/07, Junio C Hamano wrote: > Junio C Hamano writes: > > > Nicolas Pitre 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. > > Does this problem have correlation with the use of threads? Do you see > the same bloat with or without THREADED_DELTA_SEARCH defined? > I just started a non-threaded one. It will be four or five hours before it finishes. -- Jon Smirl jonsmirl@gmail.com