Re: Make the git codebase thread-safe

[Duy Nguyen <pclouds@gmail.com>]

On Tue, Apr 2, 2019 at 5:30 PM David Kastrup <dak@gnu.org> wrote:
>
> Duy Nguyen <pclouds@gmail.com> writes:
>
> > 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.
>
> I've proposed a trivial change in 2014 that could have cut down typical
> blame times significantly but nobody was interested in testing and
> committing it, and it is conceivable that in limited-memory situations
> it might warrant some accounting/mitigation for weird histories (not
> that there isn't other code like that).

I didn't really read the patch (I don't know much about blame.c to
really contribute anything there). But a quick "git blame --show-stats
unpack-trees.c" shows this

Without the patch:

num read blob: 767
num get patch: 425
num commits: 343

With the patch:

num read blob: 419
num get patch: 425
num commits: 343

That's a nice reduction of blob reading. On a typical small file, the
actual time saving might be not much. But it could really help when
you blame a large file.

Perhaps you could resubmit it again for inclusion? (at least a
sign-off-by is missing then)

> Rebased/appended.
>
> --
> David Kastrup
-- 
Duy