Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed

[Junio C Hamano <gitster@pobox.com>]

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> I haven't seen any comments on strbuf_expand.  Is it too far out?
> Here it is again, adjusted for current master and with the changes
> to strbuf.[ch] coming first:

Numbers talk ;-).

In your previous round, you alluded that the strbuf_expand()
interface could allow caching of the return value of fn(), but I
do not think strbuf_expand() in this patch has anything to
directly support that notion.

Nor I would expect to --- fn() could keep the really expensive
information cached, keyed with context value, if it wanted to,
but in practice for the purpose of format_commit_item() I do not
offhand see anything cacheable and reusable, unless the user did
stupid things (e.g. use more than one %h in the format string).

I added a few paragraphs to describe the API in the commit log
message, and rewrote "# master" to "(master)" etc.

-- >8 --
pretty=format: Avoid some expensive calculations when not needed

This rewrites the custom format prettyprinter for commit objects
by introducing a new strbuf API function "strbuf_expand()".

The function takes a format string, list of placeholder strings,
a user supplied function 'fn', and an opaque pointer 'context'
to tell 'fn' what thingy to operate on.

The function 'fn' is expected to accept a strbuf, a parsed
placeholder string and the 'context' pointer, and append the
interpolated value for the 'context' thingy, according to the
format specified by the placeholder.

Here my measurements of most of Paul's test cases (best of
three runs):

(master)
$ time git log --pretty=oneline >/dev/null

...