From: Pierre Habouzit <madcoder@debian.org>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/3] the return of the strbuf
Date: Mon, 17 Sep 2007 15:35:22 +0200 [thread overview]
Message-ID: <20070917133522.GD18176@artemis.corp> (raw)
In-Reply-To: <20070917125211.GA18176@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]
On lun, sep 17, 2007 at 12:52:11 +0000, Pierre Habouzit wrote:
> While getting rid of ->eof in strbuf (as it was somehow tasteless). It
> made me aware of the fact that fast-import.c was using a custom buffer
> implementation (I think that was the fourth if not the fifth). So here
> is the series that eradicates it.
>
> Trying to understand fast-import.c code, I happened to remark that it
> was possible to avoid many reallocations, just by reusing old buffers
> rather than dropping them (this was not possible in a readable way
> before, but it is now, and uses the same mechanisms that was garbage
> collecting buffers, to swap them instead).
>
> I've not enough stuff to do real-life tests of the old fast-import and
> the new one, but I wouldn't be surprised that it gives a quite nice
> speed improvements for tools that use long fast-import batches. If not,
> well, the code is shorter and more readable, hence it's still a gain.
Shawn: Johannes makes me remark that you are git-fast-import author,
hence may want to be Cc-ed of that series, so here is a mail so that you
don't miss the thread.
The list: it's often hard to know who you should Cc on a given change,
I use format.headers to force Junio and git@, but sometimes you want a
different set of persons. I wonder if this could not be wired in the
repository, as a .gitattribute extension ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-09-17 13:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 12:52 [PATCH 0/3] the return of the strbuf Pierre Habouzit
2007-09-17 9:19 ` [PATCH 1/3] Drop strbuf's 'eof' marker, and make read_line a first class citizen Pierre Habouzit
2007-09-17 11:48 ` [PATCH 2/3] fast-import was using dbuf's, replace them with strbuf's Pierre Habouzit
2007-09-17 12:00 ` [PATCH 3/3] fast-import optimization: Pierre Habouzit
2007-09-17 13:35 ` Pierre Habouzit [this message]
2007-09-18 3:57 ` [PATCH 0/3] the return of the strbuf Shawn O. Pearce
2007-09-20 11:49 ` Johannes Schindelin
2007-09-20 14:19 ` Shawn O. Pearce
2007-09-20 21:41 ` Junio C Hamano
2007-09-20 21:52 ` Johannes Schindelin
2007-09-18 7:56 ` Junio C Hamano
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=20070917133522.GD18176@artemis.corp \
--to=madcoder@debian.org \
--cc=git@vger.kernel.org \
--cc=spearce@spearce.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.