Re: Make the git codebase thread-safe
- From
Matheus Tavares Bernardino <matheus.bernardino@usp.br>
- Date
- Apr 2, 2019, 19:06 UTC
- Message-ID
- <CAHd-oW5K5VrbhfYw+-bWmYXbysH1z8b2kSuDvxhPKBXgXj=KXw@mail.gmail.com>
- In-Reply-To
- <CACsJy8BSDz1JO+w1N9w2W1zxY+EWTxiU6yB_V0eeOD--g-TzeA@mail.gmail.com>
On Mon, Apr 1, 2019 at 10:07 PM Duy Nguyen <pclouds@gmail.com> wrote:
Show 20 quoted lines
> > 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