Re: [PATCH 3/4] ls-files: use strbuf_add_uint()

[Jeff King <peff@peff.net>]

On Tue, May 12, 2026 at 10:44:21PM +0200, René Scharfe wrote:

> > ...also less nice. We are formatting into the strbuf, and then maybe
> > memmove()-ing the result to accommodate padding. I wonder how much that
> > affects the timing. It's extra shuffling, but memmove() etc is often
> > surprisingly fast.
> 
> I gave my objectsize and objectsize:padded numbers; the difference was
> 1.2 ms, albeit with 1.0 ms noise in padded case.

Ah, right, that makes sense.

Applying the fast decimal-width from my earlier message, I came up with:

diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index c142ad4156..e17e3517ff 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -251,22 +251,24 @@ static void expand_objectsize(struct repository *repo, struct strbuf *line,
 			      const enum object_type type, unsigned int padded)
 {
 	static const char padding[] = "       ";
-	size_t min_len = padded ? strlen(padding) : 0;
-	size_t orig_len = line->len;
-	size_t len;
+	static const unsigned padding_len = ARRAY_SIZE(padding) - 1;
 
 	if (type == OBJ_BLOB) {
 		unsigned long size;
 		if (odb_read_object_info(repo->objects, oid, &size) < 0)
 			die(_("could not get object info about '%s'"),
 			    oid_to_hex(oid));
+		if (padded) {
+			unsigned digits = decimal_length_u64(size);
+			if (digits < padding_len)
+				strbuf_add(line, padding, padding_len - digits);
+		}
 		strbuf_add_uint(line, size);
 	} else {
+		if (padded)
+			strbuf_add(line, padding, padding_len - 1);
 		strbuf_addstr(line, "-");
 	}
-	len = line->len - orig_len;
-	if (len < min_len)
-		strbuf_insert(line, orig_len, padding, min_len - len);
 }
 
 static void show_ce_fmt(struct repository *repo, const struct cache_entry *ce,

but it was not meaningfully faster than your version.

> > I have often wondered how hard it would be to implement our own
> > vsnprintf(), and whether we could do better than the libc ones. It would
> > be nice to be able to add shorthands for common types (instead of the
> > unreadable PRIuMAX mess), as well as custom ones (e.g., hex oids).
> 
> C99 has %ju for uintmax_t and %zu for size_t.  Hmm, do we actually
> still need to avoid them?  CodingGuidelines says "the C library used
> by MinGW does not" support it.  82c36fa0a9 (submodule: hash the
> submodule name for the gitdir path, 2026-01-12) just added a %zu,
> and there are lots of them in compat/mimalloc/ in Git for Windows.

An accidental test-balloon, I guess. It's in v2.54.0, so maybe we will
see some reports, or maybe we can eventually use it as evidence that we
can relax a bit.

-Peff