Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/4] strbuf: add strbuf_add_uint()
Date: Wed, 13 May 2026 12:22:32 -0400	[thread overview]
Message-ID: <20260513162232.GB103037@coredump.intra.peff.net> (raw)
In-Reply-To: <60b1ef2a-3b12-449e-be0b-cb206425c80c@web.de>

On Tue, May 12, 2026 at 09:32:09PM +0200, René Scharfe wrote:

> The three variants were close in my tests, the no-copy variant slightly
> winning on Apple silicon, but losing slightly more on an AMD Ryzen
> laptop CPU.  So I went with the solid choice of using an on-stack
> buffer, same as in printf(3) (at least on BSD).  Buffering at the end of
> the strbuf was not really faster; perhaps memmove(3) is just that much
> slower than memcpy(3).

I'm not sure if you did these tests initially, or if I nerd-sniped you
into it. Either way, I am happy to be able to hear the results. ;)

I guess it is not too surprising that they all come pretty close in
whole-process benchmarks. These are all micro-optimizations of a
relatively small portion of the total work the process is doing. Even
the strbuf_grow() checks are probably slower!

> Perhaps an optimized decimal_width() could change the picture somewhat,
> but I don't expect a big win.  On the other hand I just told you how
> unreliable my expectations are, so there might be treasure after all. :)

I got identical times for cat-file's %(objectsize:disk) running your
version against the one below. Not wanting to figure out all of the
off-by-one corner cases myself, I checked stack overflow for an easy
recipe but couldn't find one. The version below was generated by
chatgpt, which looks plausibly correct to me.

-Peff

diff --git a/strbuf.c b/strbuf.c
index 9731ecdc1f..c26614a698 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -361,16 +361,52 @@ void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
 	va_end(ap);
 }
 
+static const uint64_t powers_of_10[] = {
+    1ULL,
+    10ULL,
+    100ULL,
+    1000ULL,
+    10000ULL,
+    100000ULL,
+    1000000ULL,
+    10000000ULL,
+    100000000ULL,
+    1000000000ULL,
+    10000000000ULL,
+    100000000000ULL,
+    1000000000000ULL,
+    10000000000000ULL,
+    100000000000000ULL,
+    1000000000000000ULL,
+    10000000000000000ULL,
+    100000000000000000ULL,
+    1000000000000000000ULL,
+    10000000000000000000ULL,
+};
+
+unsigned decimal_length_u64(uint64_t n)
+{
+    if (n == 0)
+        return 1;
+
+    unsigned b = 63 - __builtin_clzll(n);
+    /* approximate floor(log10(n)) */
+    unsigned t = (b * 1233) >> 12;
+    /* correct if estimate was low */
+    return t + 1 + (n >= powers_of_10[t + 1]);
+}
+
 void strbuf_add_uint(struct strbuf *sb, uintmax_t value)
 {
-	char buf[DIV_ROUND_UP(bitsizeof(value) * 10, 33)];
-	char *end = buf + sizeof(buf);
-	char *p = end;
+	unsigned digits = decimal_length_u64(value);
+	char *p;
 
+	strbuf_grow(sb, digits);
+	p = sb->buf + digits;
 	do
 		*--p = "0123456789"[value % 10];
 	while (value /= 10);
-	strbuf_add(sb, p, end - p);
+	strbuf_setlen(sb, sb->len + digits);
 }
 
 static void add_lines(struct strbuf *out,

  reply	other threads:[~2026-05-13 16:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-12 11:55 [PATCH 0/4] strbuf: add and use strbuf_add_uint() René Scharfe
2026-05-12 11:56 ` [PATCH 1/4] strbuf: add strbuf_add_uint() René Scharfe
2026-05-12 18:42   ` Jeff King
2026-05-12 19:32     ` René Scharfe
2026-05-13 16:22       ` Jeff King [this message]
2026-05-13 16:47         ` Jeff King
2026-05-13 16:49         ` Jeff King
2026-05-14 11:09           ` René Scharfe
2026-05-14 11:53             ` Junio C Hamano
2026-05-15  3:53             ` Jeff King
2026-05-13 17:46         ` René Scharfe
2026-05-12 11:56 ` [PATCH 2/4] cat-file: use strbuf_add_uint() René Scharfe
2026-05-12 18:46   ` Jeff King
2026-05-12 11:56 ` [PATCH 3/4] ls-files: " René Scharfe
2026-05-12 19:01   ` Jeff King
2026-05-12 20:44     ` René Scharfe
2026-05-13 16:46       ` Jeff King
2026-05-12 11:56 ` [PATCH 4/4] ls-tree: " René Scharfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260513162232.GB103037@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox