[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: q: git-fetch a tad slow?
From:       "Shawn O. Pearce" <spearce () spearce ! org>
Date:       2008-07-31 21:19:19
Message-ID: 20080731211919.GC24631 () spearce ! org
[Download RAW message or body]

Ingo Molnar <mingo@elte.hu> wrote:
> 
> on another box, with 1.5.4, i have:
> 
>  dione:~/tip> time git fetch origin
> 
>  real    0m0.481s
>  user    0m0.136s
>  sys     0m0.060s
> 
>  dione:~/tip> time ./tip-fetch
>  b714d1a257cca93ba6422ca3276ac80a2cde2b59
>  b714d1a257cca93ba6422ca3276ac80a2cde2b59
> 
>  real    0m0.273s
>  user    0m0.012s
>  sys     0m0.020s
> 
> that's a 2.66 GHz core2 quad, i.e. a pretty fast box too. As you can see 
> most time spent in the tip-fetch case was waiting for the network. So 
> there's about 200 msecs of extra CPU cost on the local side.

Yea.  My testing last night was suggesting about 1/2 of that 200
ms is on the client, and the other 200 ms is on the server side
of the connection.  That matches up somewhat with your test above,
where git-fetch used about 100 ms more user time on the client side
than your tip-fetch shell script.

I have no clue where the bottleneck is, I didn't get that far before
I realized you must have been running a shell script based git-fetch
to be seeing the performance you were.

Maybe 1.6.1 or .2 we can try to squeeze fetch to run faster.
Its far too late for 1.6.0.

> Sorry that i didnt notice that titan had 1.5.2 - i almost never notice 
> it when i switch between stable git versions. (you guys are doing a 
> really good job on compatibility)

Yea, its easy to not realize your git isn't giving you the latest
and greatest toys.  ;-)

-- 
Shawn.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]