Re: q: git-fetch a tad slow?

[Ingo Molnar <mingo@elte.hu>]

* Shawn O. Pearce <spearce@spearce.org> wrote:

> > should i pack on both repos? I dont explicitly pack anything, but on 
> > the server it goes into regular gc runs. (which will pack most 
> > stuff, right?)
> 
> git-gc automatically runs `git pack-refs --all --prune` like I 
> recommended, unless you disabled it with config gc.packrefs = false. 
> So its probably already packed.
> 
> What does `find .git/refs -type f | wc -l` give for the repository on 
> the central server?  If its more than a handful (~20) I would suggest 
> running git-gc before testing again.

ah, you are right, it gave 275, then git-gc brought it down to two:

  earth4:~/tip> find .git/refs -type f | wc -l
  275
  earth4:~/tip> git gc
  earth4:~/tip> find .git/refs -type f | wc -l
  2

i turned off auto-gc recently (two weeks ago) because it was 
auto-triggering _way_ too frequently. (like on every fifth merge i was 
doing or so)

alas, fetching still seems to be slow:

  titan:~/tip> time git-fetch origin

  real    0m5.112s
  user    0m0.972s
  sys     0m3.380s

(but the gc run has not finished yet on the central repo so this isnt 
fully valid.)

> But I'm really suspecting that this is just our quadratic matching 
> algorithm running up against a large number of branches, causing it to 
> suck.
> 
> jgit at least uses an O(N) algorithm here, but since it is written in 
> Java its of course slow compared to C Git.  Takes a while to get that 
> JVM running.
> 
> I'll try to find some time to reproduce the issue and look at the 
> bottleneck here.  I'm two days into a new job so my git time has been 
> really quite short this week.  :-|

fetching the -tip repo:

   http://people.redhat.com/mingo/tip.git/README

and then running 'git remote update' will i think already show this 
problem for you too. People have been complaining about how slow the 
update is.

	Ingo