Re: [PATCH] cat-file: speed up default format

["René Scharfe" <l.s.r@web.de>]

On 6/16/26 1:12 PM, Jeff King wrote:
> On Mon, Jun 15, 2026 at 11:53:07PM +0200, René Scharfe wrote:
> 
>> We can also store literal characters in there.  An opcode plus with a
>> payload char incurs an overhead of 50%, which sounds high, but at least
>> the default format only has two of them and it's much better than
>> storing pointer plus size for an overhead of more than 90% in case of a
>> single char.
> 
> True, and it's a size win if the literal portions tend to be small
> (fewer than 15 bytes). You do lose out on the ability to strbuf_add()
> them in one go, though. So lots more strbuf_grow() checks, etc. If you
> really wanted to get fancy, you could follow the opcode with a length
> represented as a variable-sized integer, followed by the literal bytes.

Or an opcode that shovels a fixed-size string.  Depends on how much
literal text people include in their formats.

> I'm not sure that Git's formatting code needs to squeeze out quite that
> much performance, though.

Good point.  Near-native performance would be necessary to make peephole
optimizations like the special handling of the default format
unnecessary, which I understand exists to speed up Gitaly [1], but I
guess most users don't have such high demands.  And there's no point in
removing a few lines of duplicate code if the necessary machinery adds a
lot of complexity.  Though the code discussed so far was not too crazy
IMHO.

[1] https://gitlab.com/gitlab-org/gitaly/-/blob/master/internal/git/gitpipe/catfile_info.go

> OK, so we managed another 1%. But I'm skeptical that this linear opcode
> technique is where we want to go in the long run, if we're ever going to
> unify formatters.

Agreed.

René