Re: Make the git codebase thread-safe
- Date: Tue, 2 Apr 2019 16:06:57 -0300
- From: Matheus Tavares Bernardino <matheus.bernardino@xxxxxx>
- Subject: Re: Make the git codebase thread-safe
On Mon, Apr 1, 2019 at 10:07 PM Duy Nguyen <pclouds@xxxxxxxxx> wrote:
> On Tue, Apr 2, 2019 at 7:52 AM Matheus Tavares
> <matheus.bernardino@xxxxxx> 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
> > - 2m on blame for a huge file
> > - 15s on log for both  and 
> > - 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