Re: performance on repack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 16 Aug 2007, Jon Smirl wrote:

> On 8/16/07, Nicolas Pitre <nico@xxxxxxx> wrote:
> > On Thu, 16 Aug 2007, David Kastrup wrote:
> > > If I understand correctly, delta indices
> > > for the search window are kept, and the current file is compared
> > > against them.  Locality might be better if just one delta index gets
> > > calculated and then compared with all _upcoming_ delta candidates in
> > > one go.
> >
> > This appears so obvious that I attempted that a while ago already.
> >
> > The idea turned up to be so complex to implement correctly and produced
> > suboptimal results in practice that I abandoned it.
> 
> In practice it doesn't really matter what you do. Most developers have
> a decent amount of RAM. Disks run at 50MB/sec or more. The entire pack
> file ends up in the kernel disk cache within a few seconds.
> 
> Turning the twenty minute delta search into 6-7 minutes is a much more
> obvious win.

And your point in relation with what was just said is ?


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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux