git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4 1/7] Add delta-islands.{c,h}

From
Christian Couder <christian.couder@gmail.com>
Date
Aug 16, 2018, 06:04 UTC
Message-ID
<CAP8UFD0Rm6t+uiE7s=HtA1MpW7YuK_G24wadkk7AgJUpPhkrrQ@mail.gmail.com>
In-Reply-To
<20180813190005.GB10013@sigill.intra.peff.net>
On Mon, Aug 13, 2018 at 9:00 PM, Jeff King <peff@peff.net> wrote:
Show 38 quoted lines
> On Mon, Aug 13, 2018 at 05:33:59AM +0200, Christian Couder wrote:
>
>> >> +     memcpy(&sha_core, oid->hash, sizeof(uint64_t));
>> >> +     rl->hash += sha_core;
>> >
>> > Hmm, so the first 64-bits of the oid of each ref that is part of
>> > this island is added together as a 'hash' for the island. And this
>> > is used to de-duplicate the islands? Any false positives? (does it
>> > matter - it would only affect performance, not correctness, right?)
>>
>> I would think that a false positive from pure chance is very unlikely.
>> We would need to approach billions of delta islands (as 2 to the power
>> 64/2 is in the order of billions) for the probability to be
>> significant. GitHub has less than 50 millions users and it is very
>> unlikely that a significant proportion of these users will fork the
>> same repo.
>>
>> Now if there is a false positive because two forks have exactly the
>> same refs, then it is not a problem if they are considered the same,
>> because they are actually the same.
>
> Right, the idea is to find such same-ref setups to avoid spending a
> pointless bit in the per-object bitmap. In the GitHub setup, it would be
> an indication that two people forked at exactly the same time, so they
> have the same refs and the same delta requirements. If one of them later
> updates, that relationship would change at the next repack.
>
> I don't know that we ever collected numbers for how often this happens.
> So let me see if I can dig some up.
>
> On our git/git repository network, it looks like we have ~14k forks, and
> ~4k are unique by this hashing scheme. So it really is saving us
> 10k-bits per bitmap. That's over 1k-byte per object in the worst case.
> There are ~24M objects (many times what is in git.git, but people push
> lots of random things to their forks), so that's saving us up to 24GB in
> RAM. Of course it almost certainly isn't that helpful in practice, since
> we copy-on-write the bitmaps to avoid the full cost per object. But I
> think it's fair to say it is helping (more numbers below).
[...]
> So all in all (and I'd emphasize this is extremely rough) I think it
> probably costs about 2GB for the feature in this particular case. But
> you need much more to repack at this size sanely anyway.
Thanks for the interesting numbers!
Previous: Jeff KingNext: Christian Couder
Message 9 of 15 in “Add delta islands support”
  1. 0/7 Add delta islands supportChristian Couder, Aug 12, 2018
  2. 1/7 Add delta-islands.{c,h}Christian Couder, Aug 12, 2018
  3. Ramsay JonesAug 13, 2018
  4. Christian CouderAug 13, 2018
  5. Ramsay JonesAug 13, 2018
  6. Jeff KingAug 13, 2018
  7. Christian CouderAug 16, 2018
  8. Jeff KingAug 13, 2018
  9. Christian CouderAug 16, 2018
  10. 5/7 t: add t5319-delta-islands.shChristian Couder, Aug 12, 2018
  11. 2/7 pack-objects: refactor code into compute_layer_order()Christian Couder, Aug 12, 2018
  12. 4/7 repack: add delta-islands supportChristian Couder, Aug 12, 2018
  13. 3/7 pack-objects: add delta-islands supportChristian Couder, Aug 12, 2018
  14. 6/7 pack-objects: move tree_depth into 'struct packing_data'Christian Couder, Aug 12, 2018
  15. 7/7 pack-objects: move 'layer' into 'struct packing_data'Christian Couder, Aug 12, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.