Re: Make the git codebase thread-safe

[Matheus Tavares Bernardino <matheus.bernardino@usp.br>]

On Mon, Apr 1, 2019 at 10:07 PM Duy Nguyen <pclouds@gmail.com> wrote:
>
> On Tue, Apr 2, 2019 at 7:52 AM Matheus Tavares
> <matheus.bernardino@usp.br> wrote:
> > I downloaded chromium to give it a try and got (on a machine with i7 and
> > SSD, running Manjaro Linux):
> >
> > - 17s on blame for a file with long history[2]
> > - 2m on blame for a huge file[3]
> > - 15s on log for both [2] and [3]
> > - 1s for git status
> >
> > It seems quite a lot, especially with SSD, IMO.
>
> There have been a couple of optimizations that are probably still not
> enabled by default because they only benefit large repos. So you may
> want to check and turn them on before measuring anything:
> commit-graph, pack bitmap, untracked cache or fsmonitor. All these
> should be mentioned in 'git help config' (as starting point). Also
> search "threads" in that man page because some commands may have multi
> threads support but disabled by default for the same reason.

Nice, thanks for the suggestions!

> From your command list though, I think you might get the same results
> (maybe with a bit faster 'git status') even with all optimizations on.

Yes, you were right. With the optimizations on, I got the following
times on those same files:

- 17~18s on blame for about_flags.cc
- 1m50s~2m on blame for sqlite3.c
- 15s on log for both
- 0.3~0.5s on git status

> --
> Duy