git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: "Kristian Høgsberg" <krh@redhat.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf.
Date: Tue, 31 Jul 2007 15:55:25 +0100 (BST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0707311554220.14781@racer.site> (raw)
In-Reply-To: <1185891786.11086.40.camel@hinata.boston.redhat.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 882 bytes --]

Hi,

On Tue, 31 Jul 2007, Kristian H?gsberg wrote:

> On Mon, 2007-07-30 at 21:36 -0700, Junio C Hamano wrote:
> > Kristian Høgsberg <krh@redhat.com> writes:
> > 
> > > +static void inline strbuf_grow(struct strbuf *sb, size_t extra)
> > > +{
> > > +	while (sb->alloc < sb->len + extra)
> > >  		sb->alloc = sb->alloc * 3 / 2 + 16;
> > > +	sb->buf = xrealloc(sb->buf, sb->alloc);
> > > +}
> > 
> > Somehow this while () loop to compute the growth factor bothers
> > me but that is probably a minor detail.
> 
> Think of it as a more efficient way of adding one character at a time :)
> And it's logarithmic in the number of extra bytes.  By the way, I
> normally just double the size in these cases, which gives you amortized
> linear performance for adding to the buffer.  What's behind the * 3 / 2
> idea?

But why not

	sb->alloc = alloc_nr(sb->len + extra);

Hmm?

Ciao,
Dscho

  reply	other threads:[~2007-07-31 14:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-30 21:28 [PATCH 1/5] Add test case for basic commit functionality Kristian Høgsberg
2007-07-30 21:28 ` [PATCH 2/5] Enable wt-status output to a given FILE pointer Kristian Høgsberg
2007-07-30 21:28   ` [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf Kristian Høgsberg
2007-07-30 21:28     ` [PATCH 4/5] Make builtin-commit-tree use a strbuf instead of hand-rolled realloc buffer Kristian Høgsberg
2007-07-30 21:28       ` [PATCH 5/5] Split out the actual commit creation from the option parsing etc Kristian Høgsberg
2007-07-31  4:43         ` Junio C Hamano
2007-07-31 14:11           ` Kristian Høgsberg
2007-07-31  4:39       ` [PATCH 4/5] Make builtin-commit-tree use a strbuf instead of hand-rolled realloc buffer Junio C Hamano
2007-07-31  4:36     ` [PATCH 3/5] Add strbuf_printf() to do formatted printing to a strbuf Junio C Hamano
2007-07-31 14:23       ` Kristian Høgsberg
2007-07-31 14:55         ` Johannes Schindelin [this message]
2007-07-31 15:33           ` Kristian Høgsberg
2007-07-31 14:57         ` Johannes Schindelin
2007-07-31 15:28           ` Kristian Høgsberg
2007-07-31 19:54       ` [PATCH] " Kristian Høgsberg
2007-07-31 22:01         ` Junio C Hamano
2007-07-31  4:18 ` [PATCH 1/5] Add test case for basic commit functionality Junio C Hamano
2007-07-31 14:27   ` Kristian Høgsberg
2007-07-31 19:37   ` [PATCH] " Kristian Høgsberg

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=Pine.LNX.4.64.0707311554220.14781@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=krh@redhat.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).