Jeff King <peff@xxxxxxxx> writes:
> This does get called a lot (e.g., once per commit). One extra allocation
> would probably not kill us there, but I think we could fairly trivially
> put this on the unlikely path:
>
> size_t hint = 128;
> size_t len;
>
> /* optimize out obvious 0-length case */
> if (!*fmt)
> return;
>
> strbuf_grow(sb, hint);
> len = strftime(sb->buf + sb->len, sb->alloc - sb->len, fmt, tm);
>
> /* maybe not enough room, or maybe 0-length output */
> if (!len) {
> struct strbuf f = STRBUF_INIT;
> strbuf_addf(&f, "%s ", fmt);
> while (!len) {
> hint *= 2;
> strbuf_grow(sb, hint);
> len = strftime(sb->buf + sb->len, sb->alloc - sb->len, f.buf, tm);
> }
> }
>
> I'd guess most cases will fit in 128 bytes and never even hit this code
> path. You could also get fancier and start the buffer smaller, but only
> do the fmt hack when we cross a threshold.
I'd assume that the "hint" thing will persist across calls somehow?
In an invocation of "git log --date=format:<some format>" for
millions of commits, it is likely that the length of the formatted
date string will stay the same or close to the same (yeah, I know
"Wednesday" would be longer than "Monday").
Answering myself to my earlier question, the reason is because I was
worried what happens when given fmt is a malformed strftime format
specifier. Perhaps it ends with a lone % and "% " may format to
something unexpected, or something.
Are we checking an error from strftime(3)?
--
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