Re: [RFC] Speeding up a null fetch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Sun, 11 Feb 2007, Julian Phillips wrote:

> An artifical test repository that has similar features (~25000 commits,
> ~8000 tags, ~900 branches and a 2.5Gb packfile) when running locally
> takes ~20m to clone and ~48m to fetch (with no new commits in the
> original repository - i.e. the fetch does not update anything) with a
> current code base (i.e. newer than 1.5.0-rc4).

Ouch.

I hope you packed the refs?

BTW your patch
- was not minimal (and therefore it takes longer than necessary to find 
  what you actually fixed),
- it does not show where and how the call to show-ref is avoided (I 
  eventually understand that you avoid calling update_local_ref early, but 
  you sure could have made that easier), and
- it uses Pythong.

Also, it touches a quite core part of git, which will hopefully be 
replaced by a builtin _after_ 1.5.0.

> However, this seems more band-aid than fix, and I wondered if someone 
> more familiar with the git internals could point me in the right 
> direction for a better fix, e.g. should I look at rewriting fetch in C?

Look into the "pu" branch of git. There are the beginnings of a builtin 
(written in C) fetch.

But this _will_ have to wait until after 1.5.0.

Ciao,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]