Re: performance on repack

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

 



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.


>
> See http://marc.info/?l=git&m=114610715706599&w=2 for the details if
> you're interested.
>
> PS: please at least CC me when replying to my mails
>
>
> 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
>


-- 
Jon Smirl
jonsmirl@xxxxxxxxx
-
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