From: Jeff King <peff@peff.net>
To: Krzysztof Kowalczyk <kkowalczyk@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH] Optimize common pattern of alloc_ref from string
Date: Sun, 11 May 2008 04:07:09 -0400 [thread overview]
Message-ID: <20080511080709.GA6971@sigill.intra.peff.net> (raw)
In-Reply-To: <7ce338ad0805101730n5b964a0em39d9fdcd9fc45f00@mail.gmail.com>
On Sat, May 10, 2008 at 05:30:56PM -0700, Krzysztof Kowalczyk wrote:
> >> - ref = alloc_ref(strlen(refname) + 1);
> >> - strcpy(ref->name, refname);
> >> + ref = alloc_ref_from_str(refname);
> >
> > So this turns a 2-line construct into a 1-line construct...
>
> And avoids future prossible mistakes with not terminating the string,
> like the one just commited.
Yes. Please don't interpret my comment as "this change isn't worth it";
I meant it as "yes, it is good to be simplifying and making this part
less error prone; I just want to nitpick your exact implementation".
> You're absolutely right - it's a micro-optimization and your version
> might be preferred for clarity. This is the first time I submit a
> patch to git so I don't have a good feel for what kind of treadoffs
> people find acceptable.
OK. Ultimately it is up to Junio. I think your version is a bit complex,
but at the very least it contains that complexity neatly in one function.
Actually, the version I posted actually has an optimization, too (it
remembers the strlen calculation to reuse it). I think the simplest
would just be:
struct ref *alloc_ref_from_str(cons char *str)
{
struct ref *ret = alloc_ref(strlen(str) + 1);
strcpy(ret->name, str);
return ret;
}
But really my main worry is that now we have _two_ functions which
allocate refs, so if "struct ref" ever grows a new field that needs
initializing, it has to go in two places (whereas if alloc_ref_from_str
calls alloc_ref, it works automatically).
> I should also mention that
> static struct ref *try_explicit_object_name(const char *name)
> {
> unsigned char sha1[20];
> struct ref *ref;
>
> if (!*name) {
> ref = alloc_ref(20);
> strcpy(ref->name, "(delete)");
> hashclr(ref->new_sha1);
> return ref;
> }
> ...
>
> could also be replaced with alloc_ref_str() - I just wasn't 100% sure
> if overallocating 10 bytes (20 - strlen("(delete)")) was just sloppy
> code or does other code relies on that (which is unlikely and if true
> then it wouldn't be good).
It looks like just slop, and should probably be fixed at the same time.
There are also quite a number of:
ret = alloc_ref(strlen(name) + 6);
sprintf(ret->name, "refs/%s", name);
which are error-prone and owuld be nice to fix. However, I don't think
there is an easy way short of making ref->name a strbuf. And now it
seems we are getting into a lot of code churn for a relatively small
benefit.
-Peff
next prev parent reply other threads:[~2008-05-11 8:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-10 23:26 [PATCH] Optimize common pattern of alloc_ref from string kkowalczyk
2008-05-10 23:39 ` Jeff King
2008-05-11 0:30 ` Krzysztof Kowalczyk
2008-05-11 8:07 ` Jeff King [this message]
2008-05-11 18:39 ` Junio C Hamano
2008-05-11 20:15 ` Krzysztof Kowalczyk
2008-05-11 22:02 ` Junio C Hamano
2008-05-11 15:32 ` Johannes Schindelin
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=20080511080709.GA6971@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kkowalczyk@gmail.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;
as well as URLs for NNTP newsgroup(s).