Re: question about: Facebook makes Mercurial faster than Git

[Duy Nguyen <pclouds@gmail.com>]

On Mon, Mar 10, 2014 at 6:28 PM, demerphq <demerphq@gmail.com> wrote:
> I had the impression, and I would not be surprised if they had the
> impression that the git development community is relatively
> unconcerned about performance issues on larger repositories.
>
> There have been other reports, which are difficult to keep track of
> without a bug tracking system, but the ones I know of are:
>
> Poor performance of git status with large number of excluded files and
> large repositories.

I thought this has been improved lately.. I think we could do better
still, but my wip is nowhere ready for anybody's eyes.

> Poor performance, and breakage, on repositories with very large
> numbers of files in them.

index v5 and sparse checkout should help a bit. The ultimate solution,
though, is narrow clone that's nowhere near finishing. Well, if you
need all files present in worktree, then narrow clone does not help
either..

On the same line, poor performance on repos with a lot of very large
files also. Junio's split-blob series was a start, but no one picked
it up, so I guess your impression was right.

> (Rebase for instance will break if you rebase a commit that contains a *lot* of files.)

Interesting. I guess it hits shell's limitations? Roughly how many
files to break it?

> Poor performance in protocol layer (and other places) with repos with
> large numbers of refs. (Maybe this is fixed, not sure.)

Ah.. no it's not. It's being stirred up again though, in both protocol
and ref backend.
-- 
Duy