From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <junkio@cox.net>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Set up for better tree diff optimizations
Date: Wed, 21 Mar 2007 11:21:17 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0703211110050.6730@woody.linux-foundation.org> (raw)
In-Reply-To: <7vslby1qvw.fsf@assigned-by-dhcp.cox.net>
On Wed, 21 Mar 2007, Junio C Hamano wrote:
>
> As always, you are right and enlightened others with your
> superiour intelligence enough to produce code for you so that
> you do not have to write yourself ;-).
What can I say? It's a gift. I write _just_ enough code so that others get
intrigued and encouraged to do the rest. Then I step in, and take all the
glory.
> Would something like this suit your taste?
This looks fine, although the reason I didn't get it done myself is that I
have this nagging feeling that there must be some clever way to make it
even faster. I hated having to do the "strncmp()" early, when it's not
always needed.
But like your patch, I could never come up with a way to *both* do the
"don't strncmp() if you don't have to" *and* do the "nothing further will
be interesting any more" optimization..
That said, your numbers are pretty convincing:
> The "rev-list org.eclipse.debug.ui/" test that took 16-17
> seconds takes 9 seconds with this patch. Running with a
> diffrent pathspec "org.apache.ant/" obviously makes it go a lot
> faster (15sec vs 7sec).
Yeah, and conversely, a pathspec at the end of the list of paths will make
it less of an optimization. But in general it shouldn't ever be a loss
except for the rather rare case of asking for a path at the end of a tree,
and then the loss should be pretty small (ie it's the result of doing a
few strncmp's that we used to be able to skip).
Considering that the win on _average_ is in the 50% range (and your
numbers back that up), it's definitely worth it.
Linus
next prev parent reply other threads:[~2007-03-21 18:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-18 22:18 Set up for better tree diff optimizations Linus Torvalds
2007-03-21 7:09 ` Junio C Hamano
2007-03-21 15:20 ` Linus Torvalds
2007-03-21 16:51 ` Junio C Hamano
2007-03-21 18:21 ` Linus Torvalds [this message]
2007-03-21 19:05 ` Junio C Hamano
2007-03-21 19:54 ` Junio C Hamano
2007-03-22 0:00 ` 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=Pine.LNX.4.64.0703211110050.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).