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

Re: [PATCH 00/10] refs: optimize ref format migrations

From
karthik nayak <karthik.188@gmail.com>
Date
Nov 11, 2024, 10:57 UTC
Message-ID
<CAOLa=ZTGtGJDnMmuv++FS9Rv4KiRQewOepo_qOY=6h1xtNmNZA@mail.gmail.com>
In-Reply-To
<20241108-pks-refs-optimize-migrations-v1-0-7fd37fa80e35@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
Show 53 quoted lines
> Hi,
>
> I have recently learned that ref format migrations can take a
> significant amount of time in the order of minutes when migrating
> millions of refs. This is probably not entirely surprising: the initial
> focus for the logic to migrate ref backends was mostly focussed on
> getting the basic feature working, and I didn't yet invest any time into
> optimizing the code path at all. But I was still mildly surprised that
> the migration of a couple million refs was taking minutes to finish.
>
> This patch series thus optimizes how we migrate ref formats. This is
> mostly done by expanding upon the "initial transaction" semantics that
> we already use for git-clone(1). These semantics allow us to assume that
> the ref backend is completely empty and that there are no concurrent
> writers, and thus we are free to perform certain optimizations that
> wouldn't have otherwise been possible. On the one hand this allows us to
> drop needless collision checks. On the other hand, it also allows us to
> write regular refs directly into the "packed-refs" file when migrating
> from the "reftable" backend to the "files" backend.
>
> This leads to some significant speedups. Migrating 1 million refs from
> "files" to "reftable":
>
>     Benchmark 1: migrate files:reftable (refcount = 1000000, revision = origin/master)
>       Time (mean ± σ):      4.580 s ±  0.062 s    [User: 1.818 s, System: 2.746 s]
>       Range (min … max):    4.534 s …  4.743 s    10 runs
>
>     Benchmark 2: migrate files:reftable (refcount = 1000000, revision = pks-refs-optimize-migrations)
>       Time (mean ± σ):     767.7 ms ±   9.5 ms    [User: 629.2 ms, System: 126.1 ms]
>       Range (min … max):   755.8 ms … 786.9 ms    10 runs
>
>     Summary
>       migrate files:reftable (refcount = 1000000, revision = pks-refs-optimize-migrations) ran
>         5.97 ± 0.11 times faster than migrate files:reftable (refcount = 1000000, revision = origin/master)
>
> And migrating from "reftable" to "files:
>
>     Benchmark 1: migrate reftable:files (refcount = 1000000, revision = origin/master)
>       Time (mean ± σ):     35.409 s ±  0.302 s    [User: 5.061 s, System: 29.244 s]
>       Range (min … max):   35.055 s … 35.898 s    10 runs
>
>     Benchmark 2: migrate reftable:files (refcount = 1000000, revision = pks-refs-optimize-migrations)
>       Time (mean ± σ):     855.9 ms ±  61.5 ms    [User: 646.7 ms, System: 187.1 ms]
>       Range (min … max):   830.0 ms … 1030.3 ms    10 runs
>
>     Summary
>       migrate reftable:files (refcount = 1000000, revision = pks-refs-optimize-migrations) ran
>        41.37 ± 2.99 times faster than migrate reftable:files (refcount = 1000000, revision = origin/master)
>
> Thanks!
>
> Patrick
>

I read through the series, apart from a few small nits, the patches look good and straightforward.

Thanks
Previous: Patrick SteinhardtNext: Patrick Steinhardt
Message 18 of 42 in “refs: optimize ref format migrations”
  1. 00/10 refs: optimize ref format migrationsPatrick Steinhardt, Nov 8, 2024
  2. 01/10 refs: allow passing flags when setting up a transactionPatrick Steinhardt, Nov 8, 2024
  3. karthik nayakNov 11, 2024
  4. Patrick SteinhardtNov 11, 2024
  5. 02/10 refs/files: move logic to commit initial transactionPatrick Steinhardt, Nov 8, 2024
  6. 03/10 refs: introduce "initial" transaction flagPatrick Steinhardt, Nov 8, 2024
  7. 05/10 refs: use "initial" transaction semantics to migrate refsPatrick Steinhardt, Nov 8, 2024
  8. karthik nayakNov 11, 2024
  9. 06/10 refs: skip collision checks in initial transactionsPatrick Steinhardt, Nov 8, 2024
  10. karthik nayakNov 11, 2024
  11. 04/10 refs/files: support symbolic and root refs in initial transactionPatrick Steinhardt, Nov 8, 2024
  12. karthik nayakNov 11, 2024
  13. Patrick SteinhardtNov 11, 2024
  14. 09/10 reftable/block: rename `block_writer::buf` variablePatrick Steinhardt, Nov 8, 2024
  15. 08/10 reftable/writer: optimize allocations by using a scratch bufferPatrick Steinhardt, Nov 8, 2024
  16. 07/10 refs: don't normalize log messages with `REF_SKIP_CREATE_REFLOG`Patrick Steinhardt, Nov 8, 2024
  17. 10/10 reftable/block: optimize allocations by using scratch bufferPatrick Steinhardt, Nov 8, 2024
  18. karthik nayakNov 11, 2024
  19. Patrick SteinhardtNov 11, 2024
  20. Junio C HamanoNov 20, 2024
  21. Patrick SteinhardtNov 20, 2024
  22. Christian CouderNov 20, 2024
  23. Patrick SteinhardtNov 25, 2024
  24. 00/10 refs: optimize ref format migrationsPatrick Steinhardt, Nov 20, 2024
  25. 01/10 refs: allow passing flags when setting up a transactionPatrick Steinhardt, Nov 20, 2024
  26. Christian CouderNov 20, 2024
  27. 02/10 refs/files: move logic to commit initial transactionPatrick Steinhardt, Nov 20, 2024
  28. 03/10 refs: introduce "initial" transaction flagPatrick Steinhardt, Nov 20, 2024
  29. 04/10 refs/files: support symbolic and root refs in initial transactionPatrick Steinhardt, Nov 20, 2024
  30. 05/10 refs: use "initial" transaction semantics to migrate refsPatrick Steinhardt, Nov 20, 2024
  31. 06/10 refs: skip collision checks in initial transactionsPatrick Steinhardt, Nov 20, 2024
  32. Christian CouderNov 20, 2024
  33. Patrick SteinhardtNov 25, 2024
  34. Kristoffer HaugsbakkNov 20, 2024
  35. Patrick SteinhardtNov 25, 2024
  36. 07/10 refs: don't normalize log messages with `REF_SKIP_CREATE_REFLOG`Patrick Steinhardt, Nov 20, 2024
  37. 08/10 reftable/writer: optimize allocations by using a scratch bufferPatrick Steinhardt, Nov 20, 2024
  38. Christian CouderNov 20, 2024
  39. Patrick SteinhardtNov 25, 2024
  40. 09/10 reftable/block: rename `block_writer::buf` variablePatrick Steinhardt, Nov 20, 2024
  41. 10/10 reftable/block: optimize allocations by using scratch bufferPatrick Steinhardt, Nov 20, 2024
  42. Christian CouderNov 20, 2024

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.