From: Jeremiah Mahler <jmmahler@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3 1/2] add strbuf_set operations
Date: Thu, 12 Jun 2014 16:46:37 -0700 [thread overview]
Message-ID: <20140612234637.GB17803@hudson.localdomain> (raw)
In-Reply-To: <CAPig+cTVLJQOsW7H4Ht2NNYkeiMb=EWT7BG3sNu0wNsTQ=oZNA@mail.gmail.com>
Eric,
On Thu, Jun 12, 2014 at 05:48:52PM -0400, Eric Sunshine wrote:
> On Thu, Jun 12, 2014 at 3:31 PM, Jeremiah Mahler <jmmahler@gmail.com> wrote:
> > On Thu, Jun 12, 2014 at 11:50:41AM -0700, Junio C Hamano wrote:
> >> I am on the fence.
> >>
> >> I have this suspicion that the addition of strbuf_set() would *only*
> >> help when the original written with reset-and-then-add sequence was
> >> suboptimal to begin with, and it helps *only* how the code reads,
> >> without correcting the fact that it is still doing unnecessary
> >> "first set to a value to be discarded and then reset to set the
> >> right value", sweeping the issue under the rug.
> >>
> > It is certainly possible that builtin/remote.c (PATCH 2/2) saw the most
> > benefit from this operation because it is so badly designed. But this
> > seems unlikely given the review process around here ;-)
> >
> > The one case where it would be doing extra work is when a strbuf_set
> > replaces a strbuf_add that didn't previously have a strbuf_reset.
> > strbuf_set is not appropriate for all cases, as I mentioned in the
> > patch, but in some cases I think it makes it more readable. And in this
> > case it would be doing a reset on an empty strbuf. Is avoiding this
> > expense worth the reduction in readability?
> >
> > Also, as Eric Sunshine pointed out, being able to easily re-order
> > operations can make the code easier to maintain.
> >
> >> Repeated reset-and-then-add on the same strbuf used to be something
> >> that may indicate that the code is doing unnecessary work. Now,
> >> repeated uses of strbuf_set on the same strbuf replaced that pattern
> >> to be watched for to spot wasteful code paths.
> >>
> > If a reset followed by and add was a rare occurrence I would tend to
> > agree more.
>
> When composing my review of the builtin/remote.c changes, I wrote
> something like this:
>
> Although strbuf_set() does make the code a bit easier to read
> when strbufs are repeatedly re-used, re-using a variable for
> different purposes is generally considered poor programming
> practice. It's likely that heavy re-use of strbufs has been
> tolerated to avoid multiple heap allocations, but that may be a
> case of premature (allocation) optimization, rather than good
> programming. A different ("better") way to make the code more
> readable and maintainable may be to ban re-use of strbufs for
> different purposes.
>
> But I deleted it before sending because it's a somewhat tangential
> issue not introduced by your changes. However, I do see strbuf_set()
> as a Band-Aid for the problem described above, rather than as a useful
> feature on its own. If the practice of re-using strbufs (as a
> premature optimization) ever becomes taboo, then strbuf_set() loses
> its value.
>
I am getting the feeling that I have mis-understood the purpose of
strbufs. It is not just a library to use in place of char*.
If strbufs should only be added to and never reset a good test would be
to re-write builtin/remote.c without the use of strbuf_reset.
builtin/remote.c does re-use the buffers. But it seems if a buffer is
used N times then to avoid a reset you would need N buffers.
But on the other hand I agree with your comment that re-using a variable
for different purposes is poor practice.
Now I am not even sure if I want my own patch :-)
> >> I dunno...
> >>
> >> > Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
> >> > ---
> >> > Documentation/technical/api-strbuf.txt | 18 ++++++++++++++++++
> >> > strbuf.c | 21 +++++++++++++++++++++
> >> > strbuf.h | 13 +++++++++++++
> >> > 3 files changed, 52 insertions(+)
> >> >
> >> > diff --git a/Documentation/technical/api-strbuf.txt b/Documentation/technical/api-strbuf.txt
> >> > index f9c06a7..ae9c9cc 100644
> >> > --- a/Documentation/technical/api-strbuf.txt
> >> > +++ b/Documentation/technical/api-strbuf.txt
> >> > @@ -149,6 +149,24 @@ Functions
> >> > than zero if the first buffer is found, respectively, to be less than,
> >> > to match, or be greater than the second buffer.
> >> > /*----- add data in your buffer -----*/
> > ...
> >> > static inline void strbuf_addch(struct strbuf *sb, int c)
> >> > {
> >
> > --
> > Jeremiah Mahler
> > jmmahler@gmail.com
> > http://github.com/jmahler
--
Jeremiah Mahler
jmmahler@gmail.com
http://github.com/jmahler
next prev parent reply other threads:[~2014-06-12 23:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-12 7:29 [PATCH v3 0/2] add strbuf_set operations Jeremiah Mahler
2014-06-12 7:29 ` [PATCH v3 1/2] " Jeremiah Mahler
2014-06-12 8:11 ` Thomas Braun
2014-06-12 8:22 ` Jeremiah Mahler
2014-06-12 18:51 ` Junio C Hamano
2014-06-12 19:36 ` Jeremiah Mahler
2014-06-12 21:18 ` Eric Sunshine
2014-06-12 23:14 ` Jeremiah Mahler
2014-06-12 18:50 ` Junio C Hamano
2014-06-12 19:31 ` Jeremiah Mahler
2014-06-12 21:48 ` Eric Sunshine
2014-06-12 23:46 ` Jeremiah Mahler [this message]
2014-06-13 7:15 ` Jeff King
2014-06-14 4:49 ` Jeremiah Mahler
2014-06-12 7:29 ` [PATCH v3 2/2] builtin/remote: improve readability via strbuf_set() Jeremiah Mahler
2014-06-12 8:19 ` Eric Sunshine
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=20140612234637.GB17803@hudson.localdomain \
--to=jmmahler@gmail.com \
--cc=git@vger.kernel.org \
--cc=sunshine@sunshineco.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox