From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <junkio@cox.net>, Git Mailing List <git@vger.kernel.org>
Subject: [PATCH 0/3] Clean up and optimize tree walking some more
Date: Wed, 21 Mar 2007 10:07:09 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0703210955370.6730@woody.linux-foundation.org> (raw)
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
next reply other threads:[~2007-03-21 17:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-21 17:07 Linus Torvalds [this message]
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 ` Resend: [PATCH 0/3] Clean up and optimize tree walking some more Linus Torvalds
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.0703210955370.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).