Re: performance on repack

From: Nicolas Pitre <nico@cam.org>
Date: Aug 15, 2007, 19:00 UTC
Message-ID: <alpine.LFD.0.999.0708151453390.5415@xanadu.home>
In-Reply-To: <9e4733910708151138x2b267dc6w27c1bc8d948e5633@mail.gmail.com>

On Wed, 15 Aug 2007, Jon Smirl wrote:

Show 12 quoted lines

> On 8/15/07, Martin Koegler <mkoegler@auto.tuwien.ac.at> wrote:
> > git-pack-objects knows the order, in which it will use the objects.  A
> > seperate thread could pre-read the next object and wait until the main
> > thread starts processing it. After the read is complete, another
> > thread could start computing the delta index.
> 
> The hope is that the new adaptive read ahead code in the kernel will
> get this right and you won't need the second thread. Letting the
> kernel handle the read ahead will dynamically scale as other demands
> are made on the host. There's effectively only one read ahead cache in
> the system, only the kernel really knows how to divide it up between
> competing apps.

No read ahead will ever help the delta search phase. Objects listed for deltification against each other are sorted in a way that results in reads from completely random location in the object store.

Normally the delta search phase is so compute intensive that the read shouldn't matter much.

Nicolas