Re: [PATCH 3/3] introduce "format" date-mode
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 30, 2015, 17:05 UTC
- Message-ID
- <xmqqr3ot6s9u.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20150630102055.GA11928@peff.net>
Jeff King <peff@peff.net> writes:
Show 28 quoted lines
> 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)?