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

Re: [PATCH v2 5/5] notes: use strbuf_attach to take ownership of the object contents

From
MBMaarten Bosmans <mkbosmans@gmail.com>
Date
Feb 20, 2024, 07:42 UTC
Message-ID
<CA+CvcKQyXu5JzhTnfQ7W2uaJNk_aP-2bh0HqP3npsfwUJn0Cew@mail.gmail.com>
In-Reply-To
<20240220021220.GC2713741@coredump.intra.peff.net>
Op di 20 feb 2024 om 03:12 schreef Jeff King <peff@peff.net>:
Show 21 quoted lines
>
> On Sun, Feb 18, 2024 at 08:59:38PM +0100, Maarten Bosmans wrote:
>
> > @@ -705,12 +703,11 @@ static int append_edit(int argc, const char **argv, const char *prefix)
> >               if (!prev_buf)
> >                       die(_("unable to read %s"), oid_to_hex(note));
> >               if (size)
> > -                     strbuf_add(&buf, prev_buf, size);
> > +                     strbuf_attach(&buf, prev_buf, size, size + 1);
> >               if (d.buf.len && size)
> >                       append_separator(&buf);
> >               strbuf_insert(&d.buf, 0, buf.buf, buf.len);
> >
> > -             free(prev_buf);
> >               strbuf_release(&buf);
> >       }
>
> Is it possible for "size" to be 0, but prev_buf to be non-NULL? I assume
> it is so if the previous note is the empty object (and anyway, we'd have
> died earlier if prev_buf was NULL). In that case your patch introduces a
> leak (we do not attach prev_buf to buf, but we no longer free prev_buf).

You are right. I think the `if (size)` is not needed and removing it would remove the potential for a leak.

> I'm a little skeptical that this is actually increasing the speed of the
> command in a measurable way, though. It's one allocation/copy, right
> next to a big old strbuf_insert() that is going to splice into an
> existing array.

Yeah, I was doubting this patch a bit too. The simple idiom of starting with an empty strbuf and appending strings to it seems pretty nice and clear, so may be there's value in leaving it at that. The speed increase is not measurable of course. I was simply operating in full on lets-eliminate-all-sources-of-overhead mode while profiling the notes show code.

I'll drop the patch, in order to keep focus in this series.
Maarten
Previous: Jeff KingNext: Maarten Bosmans
Message 35 of 36 in “Speed up git-notes show”
  1. 0/4 Speed up git-notes showMaarten Bosmans, Feb 5, 2024
  2. 2/4 notes: use exisisting function stream_blob_to_fdMaarten Bosmans, Feb 5, 2024
  3. Eric SunshineFeb 5, 2024
  4. 1/4 notes: print note blob to stdout directlyMaarten Bosmans, Feb 5, 2024
  5. Junio C HamanoFeb 6, 2024
  6. Maarten BosmansFeb 6, 2024
  7. Junio C HamanoFeb 6, 2024
  8. Jeff KingFeb 13, 2024
  9. Junio C HamanoFeb 13, 2024
  10. Jeff KingFeb 15, 2024
  11. Junio C HamanoFeb 16, 2024
  12. Jeff KingFeb 17, 2024
  13. Junio C HamanoFeb 17, 2024
  14. Jeff KingFeb 17, 2024
  15. Maarten BosmansFeb 15, 2024
  16. Jeff KingFeb 15, 2024
  17. Maarten BosmansFeb 17, 2024
  18. Jeff KingFeb 20, 2024
  19. Maarten BosmansFeb 15, 2024
  20. Kristoffer HaugsbakkFeb 6, 2024
  21. 3/4 notes: do not clean up right before calling die()Maarten Bosmans, Feb 5, 2024
  22. 4/4 notes: use strbuf_attach to take ownership of the object contentsMaarten Bosmans, Feb 5, 2024
  23. Kristoffer HaugsbakkFeb 6, 2024
  24. Maarten BosmansFeb 6, 2024
  25. 0/5 Speed up git-notes showMaarten Bosmans, Feb 18, 2024
  26. 1/5 log: Move show_blob_object() to log.cMaarten Bosmans, Feb 18, 2024
  27. Junio C HamanoFeb 20, 2024
  28. Jeff KingFeb 20, 2024
  29. Junio C HamanoFeb 20, 2024
  30. Maarten BosmansFeb 20, 2024
  31. 3/5 notes: use existing function stream_blob_to_fdMaarten Bosmans, Feb 18, 2024
  32. 2/5 notes: avoid launching a child process to show a note blobMaarten Bosmans, Feb 18, 2024
  33. 5/5 notes: use strbuf_attach to take ownership of the object contentsMaarten Bosmans, Feb 18, 2024
  34. Jeff KingFeb 20, 2024
  35. Maarten BosmansFeb 20, 2024
  36. 4/5 notes: do not clean up right before calling die()Maarten Bosmans, Feb 18, 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.