René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> 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 ... - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
