Re: performance on repack

From: Nicolas Pitre <nico@cam.org>
Date: Aug 15, 2007, 01:59 UTC
Message-ID: <alpine.LFD.0.999.0708142127350.5415@xanadu.home>
In-Reply-To: <9e4733910708141820n9a09f08h6e104b7469f63375@mail.gmail.com>

On Tue, 14 Aug 2007, Jon Smirl wrote:

Show 30 quoted lines

> On 8/14/07, Nicolas Pitre <nico@cam.org> wrote:
> > On Mon, 13 Aug 2007, Shawn O. Pearce wrote:
> >
> > > I'm not sure its that complex to run all try_delta calls of the
> > > current window in parallel.  Might be a simple enough change that
> > > its actually worth the extra complexity, especially with these
> > > multi-core systems being so readily available.  Repacking is the
> > > most CPU intensive operation Git performs, and the one that is also
> > > the easiest to make parallel.
> > >
> > > Maybe someone else will beat me to it, but if not I might give such
> > > a patch a shot in a few weeks.
> >
> > Well, here's my quick attempt at it.  Unfortunately, performance isn't
> > as good as I'd expected, especially with relatively small blobs like
> > those found in the linux kernel repo.  It looks like the overhead of
> > thread creation/joining might be significant compared to the actual
> > delta computation.  I have a P4 with HT which might behave differently
> > from a real SMP machine, or whatever, but the CPU usage never exceeded
> > 110% according to top (sometimes it even dropped below 95%). Actually, a
> > git-repack gets much slower due to 2m27s of system time compared to
> > 0m03s without threads.  And this is with NPTL.
> 
> Thread creation/destruction overhead is way too high to make these
> threads for every delta.
> 
> Another strategy is to create four worker threads once when the
> process is loaded. Then use synchronization primitives to feed the
> threads lumps of work. The threads persist for the life of the
> process.

Still, those synchronization primitives would have to be activated for every delta which might also add some overhead.

But there is another issue to consider: delta searching is limited by previous results for the same delta. If first attempt for a delta produces a 10x reduction, then the next delta computation has to produce less than 1/10 the original object size or it is aborted early. And so on for subsequent attempts. When performing delta computations in parallel for the same target then early delta computation abort cannot occur since no result is initially available to further limit delta processing.

Segmenting the list of objects to deltify into sub-lists for individual threads solves both issues.

Nicolas