From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <junkio@cox.net>, Git Mailing List <git@vger.kernel.org>
Subject: Resend: [PATCH 0/3] Clean up and optimize tree walking some more
Date: Wed, 21 Mar 2007 11:32:06 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0703211130270.6730@woody.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0703210955370.6730@woody.linux-foundation.org>
Hmm.. There may be something wrong with my isp and/or email setup, but I
never saw this one come back to me, so I'm re-sending just in case it got
lost..
Linus
On Wed, 21 Mar 2007, Linus Torvalds wrote:
>
> This series of three patches improves blame performance on the eclipse
> tree by about 15% in my tests by improving the tree walk a bit.
>
> [ Before-best-of-five: 11.649s
> After-best-of-five: 9.675s ]
>
> The first two patches are just boring cleanups: the first removes an
> unnecessary field from the "name_entry" structure, because I wanted to
> embed it into the "tree_desc" one and it was just totally redundant and I
> felt bad about growing tree_desc more than necessary. No real code
> changes, just replacing the use of "pathlen" with the helper function we
> introduced ealier ("tree_entry_len()").
>
> The second one just makes sure that we always initialize the tree_desc
> structure with a helper function rather than doing it by hand. Again, this
> doesn't actually change any code, although I changed the name of the "buf"
> entry to "buffer", and the type of "size", so that we get nice compiler
> warnings if they are used the old way by mistake.
>
> The second patch is the largest of the lot, but really doesn't do
> anything interesting, just preparatory cleanup.
>
> The third patch is the one that actually changes any code, and is fairly
> straightforward: it just switches around where we actually do the tree
> entry parsing, which is now possible thanks to patch #2. By doing it
> up-front, we only need to do it once (we used to have to do it both when
> doing the "extract" *and* when doing the "update" op - now we do it only
> once per entry, and "extract" is just about looking at the cached
> contents).
>
> The resulting diffstat of the tree patches ends up removing a few more
> lines than it adds (not by a lot), but perhaps more importantly (even more
> than the performance advantage) the code looks nicer, I think.
>
> builtin-fsck.c | 5 +-
> builtin-grep.c | 13 +++--
> builtin-pack-objects.c | 8 +--
> builtin-read-tree.c | 3 +-
> builtin-reflog.c | 10 ++--
> fetch.c | 3 +-
> http-push.c | 3 +-
> list-objects.c | 3 +-
> merge-tree.c | 9 ++--
> reachable.c | 3 +-
> revision.c | 12 ++---
> tree-diff.c | 22 +++++----
> tree-walk.c | 123 ++++++++++++++++++++++--------------------------
> tree-walk.h | 20 ++++++--
> tree.c | 18 +++----
> unpack-trees.c | 3 +-
> 16 files changed, 125 insertions(+), 133 deletions(-)
>
> I'm pretty sure this is all good, and it obviously passes all the tests,
> but more importantly none of the changes were really very complicated, and
> patch#2 (which is the big one) was set up so that the compiler would not
> even compile code that wasn't properly converted, so it should all be
> good.
>
> Linus
>
prev parent reply other threads:[~2007-03-21 18:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-21 17:07 [PATCH 0/3] Clean up and optimize tree walking some more Linus Torvalds
2007-03-21 17:07 ` [PATCH 1/3] Remove "pathlen" from "struct name_entry" Linus Torvalds
2007-03-21 17:08 ` [PATCH 2/3] Initialize tree descriptors with a helper function rather than by hand Linus Torvalds
2007-03-21 17:09 ` [PATCH 3/3] Switch over tree descriptors to contain a pre-parsed entry Linus Torvalds
2007-03-21 18:32 ` Linus Torvalds [this message]
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.0703211130270.6730@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/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).