From: Pierre Habouzit <madcoder@debian.org>
To: git@vger.kernel.org
Subject: [PATCH 0/3] the return of the strbuf
Date: Mon, 17 Sep 2007 14:52:11 +0200 [thread overview]
Message-ID: <20070917125211.GA18176@artemis.corp> (raw)
[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]
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.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next reply other threads:[~2007-09-17 12:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 12:52 Pierre Habouzit [this message]
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 ` [PATCH 0/3] the return of the strbuf Pierre Habouzit
2007-09-18 3:57 ` 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=20070917125211.GA18176@artemis.corp \
--to=madcoder@debian.org \
--cc=git@vger.kernel.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.