* [PATCH] use strbuf_addbuf() for appending a strbuf to another
@ 2016-07-19 18:36 René Scharfe
2016-07-20 13:20 ` Jeff King
0 siblings, 1 reply; 5+ messages in thread
From: René Scharfe @ 2016-07-19 18:36 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
Use strbuf_addbuf() where possible; it's shorter and more efficient.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
dir.c | 2 +-
path.c | 2 +-
wt-status.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
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);
strbuf_add(out, ouc, ouc_size(len));
free(ouc);
diff --git a/path.c b/path.c
index 259aeed..17551c4 100644
--- a/path.c
+++ b/path.c
@@ -483,7 +483,7 @@ static void do_submodule_path(struct strbuf *buf, const char *path,
strbuf_addstr(buf, git_dir);
}
strbuf_addch(buf, '/');
- strbuf_addstr(&git_submodule_dir, buf->buf);
+ strbuf_addbuf(&git_submodule_dir, buf);
strbuf_vaddf(buf, fmt, args);
diff --git a/wt-status.c b/wt-status.c
index c19b52c..dbdb543 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1062,7 +1062,7 @@ static void abbrev_sha1_in_line(struct strbuf *line)
strbuf_addf(split[1], "%s ", abbrev);
strbuf_reset(line);
for (i = 0; split[i]; i++)
- strbuf_addf(line, "%s", split[i]->buf);
+ strbuf_addbuf(line, split[i]);
}
}
strbuf_list_free(split);
--
2.9.2
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] use strbuf_addbuf() for appending a strbuf to another
2016-07-19 18:36 [PATCH] use strbuf_addbuf() for appending a strbuf to another René Scharfe
@ 2016-07-20 13:20 ` Jeff King
2016-07-21 16:46 ` René Scharfe
0 siblings, 1 reply; 5+ messages in thread
From: Jeff King @ 2016-07-20 13:20 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Junio C Hamano
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] use strbuf_addbuf() for appending a strbuf to another
2016-07-20 13:20 ` Jeff King
@ 2016-07-21 16:46 ` René Scharfe
2016-07-21 21:02 ` Jeff King
0 siblings, 1 reply; 5+ messages in thread
From: René Scharfe @ 2016-07-21 16:46 UTC (permalink / raw)
To: Jeff King; +Cc: Git List, Junio C Hamano
Am 20.07.2016 um 15:20 schrieb Jeff King:
> 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).
Ah, I wasn't aware of that. Calling strbuf_grow() twice shouldn't be
thaaat bad. However, I wonder where we duplicate strbufs, or why we
would ever want to do so. Anyway, here's a patch for that:
-- >8 --
Subject: strbuf: avoid calling strbuf_grow() twice in strbuf_addbuf()
Implement strbuf_addbuf() as a normal function in order to avoid calling
strbuf_grow() twice, with the second callinside strbud_add() being a
no-op. This is slightly faster and also reduces the text size a bit.
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
strbuf.c | 7 +++++++
strbuf.h | 6 +-----
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index 1ba600b..f3bd571 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -197,6 +197,13 @@ void strbuf_add(struct strbuf *sb, const void *data, size_t len)
strbuf_setlen(sb, sb->len + len);
}
+void strbuf_addbuf(struct strbuf *sb, const struct strbuf *sb2)
+{
+ strbuf_grow(sb, sb2->len);
+ memcpy(sb->buf + sb->len, sb2->buf, sb2->len);
+ strbuf_setlen(sb, sb->len + sb2->len);
+}
+
void strbuf_adddup(struct strbuf *sb, size_t pos, size_t len)
{
strbuf_grow(sb, len);
diff --git a/strbuf.h b/strbuf.h
index 83c5c98..ba8d5f1 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -263,11 +263,7 @@ static inline void strbuf_addstr(struct strbuf *sb, const char *s)
/**
* Copy the contents of another buffer at the end of the current one.
*/
-static inline void strbuf_addbuf(struct strbuf *sb, const struct strbuf *sb2)
-{
- strbuf_grow(sb, sb2->len);
- strbuf_add(sb, sb2->buf, sb2->len);
-}
+extern void strbuf_addbuf(struct strbuf *sb, const struct strbuf *sb2);
/**
* Copy part of the buffer from a given position till a given length to the
--
2.9.2
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] use strbuf_addbuf() for appending a strbuf to another
2016-07-21 16:46 ` René Scharfe
@ 2016-07-21 21:02 ` Jeff King
2016-07-22 16:22 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Jeff King @ 2016-07-21 21:02 UTC (permalink / raw)
To: René Scharfe; +Cc: Git List, Junio C Hamano
On Thu, Jul 21, 2016 at 06:46:44PM +0200, René Scharfe wrote:
> >> - 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).
>
> Ah, I wasn't aware of that. Calling strbuf_grow() twice shouldn't be
> thaaat bad. However, I wonder where we duplicate strbufs, or why we
> would ever want to do so. Anyway, here's a patch for that:
I don't think we do. Going back to the original discussion:
http://thread.gmane.org/gmane.comp.version-control.git/136141/focus=136774
it was mostly just "hey, this would fail really confusingly if we ever
did, so let's make it safe".
The second strbuf_grow() is by definition a noop (which is why 81d2cae
works at all), but we do pay the size-computation cost.
> -- >8 --
> Subject: strbuf: avoid calling strbuf_grow() twice in strbuf_addbuf()
>
> Implement strbuf_addbuf() as a normal function in order to avoid calling
> strbuf_grow() twice, with the second callinside strbud_add() being a
> no-op. This is slightly faster and also reduces the text size a bit.
Seems reasonable. IMHO the main advantage is that one does not have to
reason about the double strbuf_grow() (i.e., that the strbuf_add() is
safe because we know its grow is a noop).
-Peff
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] use strbuf_addbuf() for appending a strbuf to another
2016-07-21 21:02 ` Jeff King
@ 2016-07-22 16:22 ` Junio C Hamano
0 siblings, 0 replies; 5+ messages in thread
From: Junio C Hamano @ 2016-07-22 16:22 UTC (permalink / raw)
To: Jeff King; +Cc: René Scharfe, Git List
Jeff King <peff@peff.net> writes:
> I don't think we do. Going back to the original discussion:
>
> http://thread.gmane.org/gmane.comp.version-control.git/136141/focus=136774
>
> it was mostly just "hey, this would fail really confusingly if we ever
> did, so let's make it safe".
>
> The second strbuf_grow() is by definition a noop (which is why 81d2cae
> works at all), but we do pay the size-computation cost.
Both true. If the second one is not a noop, nothing is fixed by
81d2cae at all, but it is subtle.
René's update makes it far easier to understand what is going on.
>> -- >8 --
>> Subject: strbuf: avoid calling strbuf_grow() twice in strbuf_addbuf()
>>
>> Implement strbuf_addbuf() as a normal function in order to avoid calling
>> strbuf_grow() twice, with the second callinside strbud_add() being a
>> no-op. This is slightly faster and also reduces the text size a bit.
>
> Seems reasonable. IMHO the main advantage is that one does not have to
> reason about the double strbuf_grow() (i.e., that the strbuf_add() is
> safe because we know its grow is a noop).
>
> -Peff
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-07-22 16:22 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-19 18:36 [PATCH] use strbuf_addbuf() for appending a strbuf to another René Scharfe
2016-07-20 13:20 ` Jeff King
2016-07-21 16:46 ` René Scharfe
2016-07-21 21:02 ` Jeff King
2016-07-22 16:22 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).