Re: Make the git codebase thread-safe

From: Duy Nguyen <pclouds@gmail.com>
Date: Apr 2, 2019, 11:35 UTC
Message-ID: <CACsJy8BuJbxj5fHwTc+aogWcWGR_6A0CXS78-h0zi4rYLa0kXQ@mail.gmail.com>
In-Reply-To: <87lg0s66nm.fsf@fencepost.gnu.org>

On Tue, Apr 2, 2019 at 5:30 PM David Kastrup <dak@gnu.org> wrote:

Show 23 quoted lines

>
> 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