Re: [PATCH v2 11/19] pack-objects: use bitmaps when packing objects

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

 



On Fri, Oct 25, 2013 at 1:03 PM, Jeff King <peff@xxxxxxxx> wrote:
> From: Vicent Marti <tanoku@xxxxxxxxx>
>
> In this patch, we use the bitmap API to perform the `Counting Objects`
> phase in pack-objects, rather than a traditional walk through the object
> graph. For a reasonably-packed large repo, the time to fetch and clone
> is often dominated by the full-object revision walk during the Counting
> Objects phase. Using bitmaps can reduce the CPU time required on the
> server (and therefore start sending the actual pack data with less
> delay).
>
> For bitmaps to be used, the following must be true:
>
>   1. We must be packing to stdout (as a normal `pack-objects` from
>      `upload-pack` would do).
>
>   2. There must be a .bitmap index containing at least one of the
>      "have" objects that the client is asking for.
>
>   3. Bitmaps must be enabled (they are enabled by default, but can be
>      disabled by setting `pack.usebitmaps` to false, or by using
>      `--no-use-bitmap-index` on the command-line).
>
> If any of these is not true, we fall back to doing a normal walk of the
> object graph.

I haven't read the bitmap creation code yet. But it probably does not
matter. If the client requests a shallow fetch, you probably want to
fall back to normal walk too.

Bitmaps may be made work with shallow fetches too, I'm not sure. We
could substract the shallow'd commits out. The problem is if some
other commits share parts of the shallow'd commits, I'm not sure how
to detect that.
-- 
Duy
--
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]