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

Re: [PATCH 1/6] fetch: speed up lookup of want refs via commit-graph

From
Derrick Stolee <stolee@gmail.com>
Date
Aug 25, 2021, 14:12 UTC
Message-ID
<b2b2316e-3d2c-4561-3da8-2d3a5ca243e0@gmail.com>
In-Reply-To
<YSNEQ9R0TDUNPZPM@ncase>
On 8/23/2021 2:46 AM, Patrick Steinhardt wrote:
Show 33 quoted lines
> On Fri, Aug 20, 2021 at 10:18:22AM -0700, Junio C Hamano wrote:
>> Derrick Stolee <stolee@gmail.com> writes:
>>
>>> I do worry about the case where annotated tags greatly outnumber
>>> branches, so this binary search is extra overhead and the performance
>>> may degrade. Would it be worth checking the ref to see if it lies
>>> within "refs/heads/" (or even _not_ in "refs/tags/") before doing
>>> this commit-graph check?
>>
>> Ah, clever.
> 
> Good idea. Benchmarks for my test repository (which definitely isn't
> representative, but it's at least some numbers) show that restricting to
> "refs/heads/" diminishes almost all the gains, while restricting to
> everything but "refs/tags/" performs almost the same (it's a tiny bit
> slower, probably because of the added string comparisons):
> 
>     Benchmark #1: all refs: git-fetch
>       Time (mean ± σ):     32.959 s ±  0.282 s    [User: 29.801 s, System: 5.137 s]
>       Range (min … max):   32.760 s … 33.158 s    2 runs
> 
>     Benchmark #2: refs/heads: git-fetch
>       Time (mean ± σ):     56.955 s ±  0.002 s    [User: 53.447 s, System: 5.362 s]
>       Range (min … max):   56.953 s … 56.957 s    2 runs
> 
>     Benchmark #3: !refs/tags: git-fetch
>       Time (mean ± σ):     33.447 s ±  0.003 s    [User: 30.160 s, System: 5.027 s]
>       Range (min … max):   33.444 s … 33.449 s    2 runs
> 
>     Summary
>       'all refs: git-fetch' ran
>         1.01 ± 0.01 times faster than '!refs/tags: git-fetch'
>         1.73 ± 0.01 times faster than 'refs/heads: git-fetch'
Thanks for testing both options.
> This is easily explained by the fact that the test repo has most of its
> refs neither in "refs/tags/" nor in "refs/heads/", but rather in special
> namespaces like "refs/merge-requests/", "refs/environments/" or
> "refs/keep-around/".

That makes sense to me. GitHub also stores refs like refs/pull/ so I can understand not wanting to restrict to refs/heads/.

> I like the idea of excluding "refs/tags/" though: as you point out,
> chances are high that these don't point to commits but to annotated tags
> instead. So I'll go with that, thanks!
Yeah, that makes sense as a good way forward.

Thanks, -Stolee

Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 6 of 48 in “Speed up mirror-fetches with many refs”
  1. 0/6 Speed up mirror-fetches with many refsPatrick Steinhardt, Aug 20, 2021
  2. 1/6 fetch: speed up lookup of want refs via commit-graphPatrick Steinhardt, Aug 20, 2021
  3. Derrick StoleeAug 20, 2021
  4. Junio C HamanoAug 20, 2021
  5. Patrick SteinhardtAug 23, 2021
  6. Derrick StoleeAug 25, 2021
  7. 2/6 fetch: avoid unpacking headers in object existence checkPatrick Steinhardt, Aug 20, 2021
  8. Ævar Arnfjörð BjarmasonAug 25, 2021
  9. 3/6 connected: refactor iterator to return next object ID directlyPatrick Steinhardt, Aug 20, 2021
  10. Derrick StoleeAug 20, 2021
  11. Junio C HamanoAug 20, 2021
  12. René ScharfeAug 20, 2021
  13. Patrick SteinhardtAug 23, 2021
  14. 4/6 fetch-pack: optimize loading of refs via commit graphPatrick Steinhardt, Aug 20, 2021
  15. Derrick StoleeAug 20, 2021
  16. 5/6 fetch: refactor fetch refs to be more extendablePatrick Steinhardt, Aug 20, 2021
  17. Derrick StoleeAug 20, 2021
  18. 6/6 fetch: avoid second connectivity check if we already have all objectsPatrick Steinhardt, Aug 20, 2021
  19. Derrick StoleeAug 20, 2021
  20. Patrick SteinhardtAug 23, 2021
  21. Derrick StoleeAug 20, 2021
  22. Junio C HamanoAug 21, 2021
  23. 0/7 Speed up mirror-fetches with many refsPatrick Steinhardt, Aug 24, 2021
  24. 1/7 fetch: speed up lookup of want refs via commit-graphPatrick Steinhardt, Aug 24, 2021
  25. Derrick StoleeAug 25, 2021
  26. 2/7 fetch: avoid unpacking headers in object existence checkPatrick Steinhardt, Aug 24, 2021
  27. 3/7 connected: refactor iterator to return next object ID directlyPatrick Steinhardt, Aug 24, 2021
  28. 4/7 fetch-pack: optimize loading of refs via commit graphPatrick Steinhardt, Aug 24, 2021
  29. 5/7 fetch: refactor fetch refs to be more extendablePatrick Steinhardt, Aug 24, 2021
  30. Derrick StoleeAug 25, 2021
  31. Patrick SteinhardtSep 1, 2021
  32. 7/7 fetch: avoid second connectivity check if we already have all objectsPatrick Steinhardt, Aug 24, 2021
  33. 6/7 fetch: merge fetching and consuming refsPatrick Steinhardt, Aug 24, 2021
  34. Derrick StoleeAug 25, 2021
  35. Patrick SteinhardtSep 1, 2021
  36. Junio C HamanoAug 24, 2021
  37. Patrick SteinhardtAug 25, 2021
  38. Derrick StoleeAug 25, 2021
  39. 0/7 Speed up mirror-fetches with many refsPatrick Steinhardt, Sep 1, 2021
  40. 1/7 fetch: speed up lookup of want refs via commit-graphPatrick Steinhardt, Sep 1, 2021
  41. 2/7 fetch: avoid unpacking headers in object existence checkPatrick Steinhardt, Sep 1, 2021
  42. 3/7 connected: refactor iterator to return next object ID directlyPatrick Steinhardt, Sep 1, 2021
  43. 4/7 fetch-pack: optimize loading of refs via commit graphPatrick Steinhardt, Sep 1, 2021
  44. 5/7 fetch: refactor fetch refs to be more extendablePatrick Steinhardt, Sep 1, 2021
  45. 6/7 fetch: merge fetching and consuming refsPatrick Steinhardt, Sep 1, 2021
  46. 7/7 fetch: avoid second connectivity check if we already have all objectsPatrick Steinhardt, Sep 1, 2021
  47. Junio C HamanoSep 1, 2021
  48. Junio C HamanoSep 8, 2021

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.