git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).