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

Re: [PATCH v3 5/8] reftable/record: store "val1" hashes as static arrays

From
Patrick Steinhardt <ps@pks.im>
Date
Feb 6, 2024, 06:03 UTC
Message-ID
<ZcHLpkrIG07U4Ep2@tanuki>
In-Reply-To
<CAOLa=ZQk_SocUWkoTgJuKyyGWVU85gtw+=8o1ffgBQmh5dQnqQ@mail.gmail.com>
On Mon, Feb 05, 2024 at 03:39:31AM -0800, Karthik Nayak wrote:
Show 26 quoted lines
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > When reading ref records of type "val1", we store its object ID in an
> > allocated array. This results in an additional allocation for every
> > single ref record we read, which is rather inefficient especially when
> > iterating over refs.
> >
> > Refactor the code to instead use an embedded array of `GIT_MAX_RAWSZ`
> > bytes. While this means that `struct ref_record` is bigger now, we
> > typically do not store all refs in an array anyway and instead only
> > handle a limited number of records at the same point in time.
> >
> > Using `git show-ref --quiet` in a repository with ~350k refs this leads
> > to a significant drop in allocations. Before:
> >
> >     HEAP SUMMARY:
> >         in use at exit: 21,098 bytes in 192 blocks
> >       total heap usage: 2,116,683 allocs, 2,116,491 frees, 76,098,060 bytes allocated
> >
> > After:
> >
> >     HEAP SUMMARY:
> >         in use at exit: 21,098 bytes in 192 blocks
> >       total heap usage: 1,419,031 allocs, 1,418,839 frees, 62,145,036 bytes allocated
> 
> Curious, did you also do perf benchmarking on this?

I didn't back then, but here you go. The following test shows a single ref matching a specific pattern out of 1 million refs:

    Benchmark 1: show-ref: single matching ref (revision = HEAD~)
      Time (mean ± σ):     191.1 ms ±   5.2 ms    [User: 188.1 ms, System: 2.8 ms]
      Range (min … max):   186.2 ms … 214.5 ms    100 runs
    Benchmark 2: show-ref: single matching ref (revision = HEAD)
      Time (mean ± σ):     189.7 ms ±   5.3 ms    [User: 186.7 ms, System: 2.8 ms]
      Range (min … max):   184.1 ms … 213.4 ms    100 runs
    Summary
      show-ref: single matching ref (revision = HEAD) ran
        1.01 ± 0.04 times faster than show-ref: single matching ref (revision = HEAD~)

Not much of a win here, which is probably expected. On glibc the allocator seems to be really efficient churning out many small blocks of memory, which is also something I have noticed in other contexts. I do expect that other platorms might see more significant results.

Patrick
Previous: Karthik NayakNext: Patrick Steinhardt
Message 32 of 36 in “reftable: fixes and optimizations (pt.2)”
  1. 0/7 reftable: fixes and optimizations (pt.2)Patrick Steinhardt, Dec 20, 2023
  2. 1/7 reftable/stack: do not overwrite errors when compactingPatrick Steinhardt, Dec 20, 2023
  3. 2/7 reftable/writer: fix index corruption when writing multiple indicesPatrick Steinhardt, Dec 20, 2023
  4. 3/7 reftable/record: constify some parts of the interfacePatrick Steinhardt, Dec 20, 2023
  5. 4/7 reftable/record: store "val1" hashes as static arraysPatrick Steinhardt, Dec 20, 2023
  6. Patrick SteinhardtDec 20, 2023
  7. 5/7 reftable/record: store "val2" hashes as static arraysPatrick Steinhardt, Dec 20, 2023
  8. 6/7 reftable/merged: really reuse buffers to compute record keysPatrick Steinhardt, Dec 20, 2023
  9. 7/7 reftable/merged: transfer ownership of records when iteratingPatrick Steinhardt, Dec 20, 2023
  10. Junio C HamanoDec 20, 2023
  11. 0/8 reftable: fixes and optimizations (pt.2)Patrick Steinhardt, Dec 28, 2023
  12. 1/8 reftable/stack: do not overwrite errors when compactingPatrick Steinhardt, Dec 28, 2023
  13. 2/8 reftable/stack: do not auto-compact twice in `reftable_stack_add()`Patrick Steinhardt, Dec 28, 2023
  14. 3/8 reftable/writer: fix index corruption when writing multiple indicesPatrick Steinhardt, Dec 28, 2023
  15. 4/8 reftable/record: constify some parts of the interfacePatrick Steinhardt, Dec 28, 2023
  16. 5/8 reftable/record: store "val1" hashes as static arraysPatrick Steinhardt, Dec 28, 2023
  17. Junio C HamanoDec 28, 2023
  18. 6/8 reftable/record: store "val2" hashes as static arraysPatrick Steinhardt, Dec 28, 2023
  19. 7/8 reftable/merged: really reuse buffers to compute record keysPatrick Steinhardt, Dec 28, 2023
  20. Junio C HamanoDec 28, 2023
  21. 8/8 reftable/merged: transfer ownership of records when iteratingPatrick Steinhardt, Dec 28, 2023
  22. Junio C HamanoDec 28, 2023
  23. 0/8 reftable: fixes and optimizations (pt.2)Patrick Steinhardt, Jan 3, 2024
  24. 1/8 reftable/stack: do not overwrite errors when compactingPatrick Steinhardt, Jan 3, 2024
  25. Han-Wen NienhuysFeb 14, 2024
  26. Patrick SteinhardtFeb 15, 2024
  27. 2/8 reftable/stack: do not auto-compact twice in `reftable_stack_add()`Patrick Steinhardt, Jan 3, 2024
  28. 3/8 reftable/writer: fix index corruption when writing multiple indicesPatrick Steinhardt, Jan 3, 2024
  29. 4/8 reftable/record: constify some parts of the interfacePatrick Steinhardt, Jan 3, 2024
  30. 5/8 reftable/record: store "val1" hashes as static arraysPatrick Steinhardt, Jan 3, 2024
  31. Karthik NayakFeb 5, 2024
  32. Patrick SteinhardtFeb 6, 2024
  33. 6/8 reftable/record: store "val2" hashes as static arraysPatrick Steinhardt, Jan 3, 2024
  34. 7/8 reftable/merged: really reuse buffers to compute record keysPatrick Steinhardt, Jan 3, 2024
  35. 8/8 reftable/merged: transfer ownership of records when iteratingPatrick Steinhardt, Jan 3, 2024
  36. Karthik NayakFeb 5, 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.