From: Linus Torvalds <torvalds@osdl.org>
To: Keith Packard <keithp@keithp.com>
Cc: Git Mailing List <git@vger.kernel.org>, Junio C Hamano <junkio@cox.net>
Subject: Re: git-fetch per-repository speed issues
Date: Mon, 3 Jul 2006 20:21:30 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0607032008590.12404@g5.osdl.org> (raw)
In-Reply-To: <1151973438.4723.70.camel@neko.keithp.com>
On Mon, 3 Jul 2006, Keith Packard wrote:
> On Mon, 2006-07-03 at 16:14 -0700, Linus Torvalds wrote:
> >
> > Well, you could use multiple branches in the same repository, even if they
> > are totally unrealated. That would allow you to fetch them all in one go.
>
> I'd like to avoid this; the hope is that most people won't ever need to
> look at most repositories; it would be somewhat like having glibc in the
> same repo as the kernel...
Sure, understood. I'm just saying that if you want to fetch in one go,
it's one possibility.
However, your setup has something else seriously wrong.
> Yeah, I tried with the git protocol and it's a few seconds faster (about
> 14 seconds instead of 17). Ick.
That's -still- about 13 seconds too much.
> I think it might have something to do with the number of heads we're
> tracking.
It really shouldn't matter. You get all the heads in one go with a single
connection, so if 32 heads takes 32 times longer, there's something wrong.
> > Also, one thing to try is to just do
> >
> > strace -Ttt git-peek-remote ...
>
> That's plenty fast, 0.410 seconds, with nothing ugly in the strace.
Ok, a "git fetch" really shouldn't take any longer than a single
connection. However, the fact that you have 32 heads, and it takes pretty
close to _exactly_ 32 times 0.410 seconds (32*0.410s = 13.1s) makes me
suspect that "git fetch" is just broken and fetches one branch at a time.
Which would be just stupid.
But look as I might, I see only that one "git-fetch-pack" in git-fetch.sh
that should trigger. Once. Not 32 times. But your timings sure sound like
it's doing a _lot_ more than it should.
Junio, any ideas?
Keithp, can you try this trivial patch? It _should_ say something like
Fetching
refs/heads/master
refs/heads/...
refs/heads/...
...
refs/heads/... from git://..../...
and more importantly, it should say so only once.
And then it should leave a "fetch.trace" file in your working directory,
which should show where that _one_ thing spends its time.
Linus
----
diff --git a/git-fetch.sh b/git-fetch.sh
index 48818f8..4739202 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -339,6 +339,8 @@ fetch_main () {
( : subshell because we muck with IFS
IFS=" $LF"
(
+ echo "Fetching $rref from $remote" >&2
+ strace -o fetch.trace -Ttt \
git-fetch-pack $exec $keep --thin "$remote" $rref || echo failed "$remote"
) |
while read sha1 remote_name
next prev parent reply other threads:[~2006-07-04 3:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-03 18:02 git-fetch per-repository speed issues Keith Packard
2006-07-03 23:14 ` Linus Torvalds
2006-07-04 0:21 ` Jeff King
2006-07-04 1:22 ` Ryan Anderson
2006-07-04 1:44 ` Jeff King
2006-07-04 1:55 ` Ryan Anderson
2006-07-04 3:07 ` Linus Torvalds
2006-07-05 6:47 ` Jeff King
2006-07-05 16:40 ` Linus Torvalds
2006-07-04 6:44 ` Jakub Narebski
[not found] ` <1151973438.4723.70.camel@neko.keithp.com>
2006-07-04 3:21 ` Linus Torvalds [this message]
2006-07-04 3:30 ` Junio C Hamano
2006-07-04 3:40 ` Linus Torvalds
2006-07-04 4:30 ` Keith Packard
2006-07-04 11:10 ` Andreas Ericsson
2006-07-04 11:18 ` Matthias Kestenholz
2006-07-04 12:05 ` Andreas Ericsson
2006-07-04 4:02 ` Keith Packard
2006-07-04 4:19 ` Linus Torvalds
2006-07-04 5:05 ` Keith Packard
2006-07-04 5:36 ` Linus Torvalds
2006-07-04 6:21 ` Junio C Hamano
2006-07-04 5:29 ` Keith Packard
2006-07-04 5:53 ` Linus Torvalds
2006-07-04 15:42 ` Jakub Narebski
2006-07-04 16:30 ` Thomas Glanzmann
2006-07-04 17:45 ` Junio C Hamano
2006-07-04 19:22 ` Linus Torvalds
2006-07-04 21:05 ` Junio C Hamano
2006-07-06 23:36 ` David Woodhouse
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.0607032008590.12404@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
--cc=keithp@keithp.com \
/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).