From: Jeff King <peff@peff.net>
To: "René Scharfe" <l.s.r@web.de>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] use strbuf_addbuf() for appending a strbuf to another
Date: Wed, 20 Jul 2016 07:20:25 -0600 [thread overview]
Message-ID: <20160720132025.GD17469@sigill.intra.peff.net> (raw)
In-Reply-To: <578E732D.2090803@web.de>
On Tue, Jul 19, 2016 at 08:36:29PM +0200, René Scharfe wrote:
> Use strbuf_addbuf() where possible; it's shorter and more efficient.
After seeing "efficient", I was momentarily surprised by the first hunk:
> diff --git a/dir.c b/dir.c
> index 6172b34..0ea235f 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -2364,7 +2364,7 @@ void write_untracked_extension(struct strbuf *out, struct untracked_cache *untra
>
> varint_len = encode_varint(untracked->ident.len, varbuf);
> strbuf_add(out, varbuf, varint_len);
> - strbuf_add(out, untracked->ident.buf, untracked->ident.len);
> + strbuf_addbuf(out, &untracked->ident);
This is actually slightly _less_ efficient, because we already are using
the precomputed len, and the new code will call an extra strbuf_grow()
to cover the case where the two arguments are the same. See 81d2cae
(strbuf_addbuf(): allow passing the same buf to dst and src,
2010-01-12).
But it almost certainly doesn't matter, and it definitely _is_ an
improvement for the other "addstr" cases, which are doing an unncessary
strlen().
And anyway the readability improvement trumps all of that in my mind. So
I think overall it is a nice cleanup; I'm mostly just commenting for the
sake of other reviewers.
-Peff
next prev parent reply other threads:[~2016-07-20 13:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 18:36 [PATCH] use strbuf_addbuf() for appending a strbuf to another René Scharfe
2016-07-20 13:20 ` Jeff King [this message]
2016-07-21 16:46 ` René Scharfe
2016-07-21 21:02 ` Jeff King
2016-07-22 16:22 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160720132025.GD17469@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.