git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).