git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff Hostetler <git@jeffhostetler.com>,
	Christian Couder <christian.couder@gmail.com>,
	git@vger.kernel.org, Jeff Hostetler <jeffhost@microsoft.com>,
	Jonathan Tan <jonathantanmy@google.com>,
	Derrick Stolee <stolee@gmail.com>, Kevin Daudt <me@ikke.info>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v2 2/2] sha1_file: improve sha1_file_name() perfs
Date: Wed, 17 Jan 2018 17:27:07 -0500	[thread overview]
Message-ID: <20180117222707.GA16031@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqq4lnkryt2.fsf@gitster.mtv.corp.google.com>

On Wed, Jan 17, 2018 at 12:54:33PM -0800, Junio C Hamano wrote:

> Jeff Hostetler <git@jeffhostetler.com> writes:
> 
> >>     void sha1_file_name(struct strbuf *buf, const unsigned char
> >> *sha1)
> >>   {
> >> -	strbuf_addf(buf, "%s/", get_object_directory());
> >> +	const char *obj_dir = get_object_directory();
> >> +	size_t extra = strlen(obj_dir) + 1 + GIT_MAX_HEXSZ;
> >
> > Very minor nit.  Should this be "+3" rather than "+1"?
> > One for the slash after obj_dir, one for the slash between
> > "xx/y[38]", and one for the trailing NUL.
> >
> >>   +	if (extra > strbuf_avail(buf))
> >> +		strbuf_grow(buf, extra);
> 
> The callers who care use static strbuf with 1/2, which lets them
> grow it to an appropriate size after they make their first call.
> 
> On the other hand, the ones to which performance does not matter by
> definition do not care.
> 
> I actually think this whole "extra -> grow" business should be
> discarded.  With a miscomputed "extra" like this, it does not help
> anybody---everybody may pay cost for one extra realloc due to the
> miscalculation, and the ones that do care also do during their first
> call.

Let me second that. The diffstat here, along with the magic numbers, is
not really encouraging unless we have a demonstrable speedup. In which
case we can then measure and compare other approaches, like pushing a
static strbuf farther up the stack. But without that, it feels like
stumbling around in the dark.

-Peff

  reply	other threads:[~2018-01-17 22:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-17 17:54 [PATCH v2 1/2] sha1_file: remove static strbuf from sha1_file_name() Christian Couder
2018-01-17 17:54 ` [PATCH v2 2/2] sha1_file: improve sha1_file_name() perfs Christian Couder
2018-01-17 20:37   ` Jeff Hostetler
2018-01-17 20:54     ` Junio C Hamano
2018-01-17 22:27       ` Jeff King [this message]
2018-01-17 21:44     ` Christian Couder

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180117222707.GA16031@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jeffhost@microsoft.com \
    --cc=jonathantanmy@google.com \
    --cc=me@ikke.info \
    --cc=stolee@gmail.com \
    --subject='Re: [PATCH v2 2/2] sha1_file: improve sha1_file_name() perfs' \
    /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

Code repositories for project(s) associated with this 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).